IPsec över ett privat WAN: SRX-policygränser att kontrollera

Ett privat WAN kan bära de yttre paketen i en IPsec-tunnel, så peer-adresserna behöver inte vara offentliga internetadresser. Det som ändras är vägen som dessa yttre paket tar och behörigheterna på gränssnittet som tar emot dem. På en SRX är den yttre kontrollvägen, bindningen av tunnelgränssnittet och policyn för vidarebefordrad trafik tre separata objekt. Felsökning på en medan de andra två är fel är det vanliga skälet till att en tunnel blir kvar nere.

Anteckna den yttre IKE-vägen först

Skriv ned fyra värden innan du rör policyn: peer-adressen, det lokala gränssnittet som tar emot IKE, routingkontexten som når peer och rutten som väljer det gränssnittet. IKE-paket är adresserade till SRX:en själv, så de behöver host-inbound-behörighet i mottagningszonen, inte en policy för vidarebefordrad trafik. En privat WAN-adress tar inte bort det kravet, eftersom paketet fortfarande avslutas på enheten.

Kontrollera det installerade tillståndet med show security ike sa och konfigurationen med show configuration security ike. Den första visar om fas 1 finns; den andra visar vad enheten tror att den borde göra.

Bind tunnelgränssnittet till rätt policy

En ruttbaserad VPN binder ett tunnelgränssnitt till ett VPN-objekt, och skyddade prefix routas in i det gränssnittet. Anteckna vilket gränssnitt, vilken rutt och vilken policy som tillåter applikationerna mellan de relevanta zonerna. En zon med namnet trust är en policybehållare, och namnet bevisar inte att de nödvändiga kontroll- eller datapaketen är tillåtna.

Läs de faktiska bindningarna i stället för ett gammalt diagram: show configuration security ipsec vpn för inställningen bind-to-interface och show configuration security policies för reglerna som refererar till tunnelzonen.

Om den skyddade rutten pekar någon annanstans kan tunneln vara uppe medan trafiken aldrig kommer in i den. Det är ett routingproblem i IPsec-kostym.

Håll peer-rutten på underlayet

Rutten till den externa peeren måste lösas genom underlayet, inte rekursivt genom tunneln den etablerar. Om peer-rutten pekar på tunnelgränssnittet jagar IKE-paketen sin egen tunnel och fas 1 slutförs aldrig. Svarsvägen för skyddad trafik behöver sin egen korrekta rutt och policy, och det är vanligtvis den saknade halvan när en riktning fungerar. Läs routingtabellposten för peer-adressen och bekräfta att det utgående gränssnittet är WAN-gränssnittet.

Kontrollera det med show route 198.51.100.10, sätt in den riktiga peer-adressen, och bekräfta att nästa hopp inte är ett tunnelgränssnitt.

Verifiera kontroll och tjänst i ordning

Arbeta uppåt: fas 1-tillstånd, fas 2-tillstånd och sedan ett verkligt applikationsflöde. show security ipsec sa listar säkerhetsassociationerna, och show security flow session destination-prefix 10.60.0.0/16 visar om vidarebefordrade sessioner skapas för det skyddade nätverket.

En sund kontrollrelation och en fungerande dataväg är två olika resultat, och att fas 2 passerar säger ingenting om huruvida policyn tillåter applikationen. Testa ett tillåtet flöde och ett som policyn borde avvisa, så att skillnaden syns.

Anteckna peer-rutten, host-inbound-behörigheten, tunnelbindningen, den inre rutten och applikationspolicyn tillsammans. Dessa fem poster visar vilket lager som äger ett framtida fel utan att förlita sig på en portetikett.