ASA identity NAT versus IOS NAT-uitzondering voor VPN-verkeer

Een vestiging draait internet-PAT en een site-to-site-VPN op dezelfde Cisco-gateway, en de VPN stopt met werken op het moment dat NAT wordt toegevoegd. De adressen in de tunnel komen niet meer overeen met wat de crypto-ACL beschermt, of de peer ziet vertaalde adressen waarvoor hij geen route heeft. Cisco lost dit op twee plaatsen op: de ASA kiest een NAT-regel die een adres op zichzelf afbeeldt, terwijl IOS de flow via een deny in de ACL buiten een vertaalregel houdt. Beide behouden de oorspronkelijke adressen, en geen van beide is een omzeiling van NAT-verwerking.

Leg de flow vast voordat je een regel kiest

Begin met het opschrijven van de flow die je wilt beschermen: de LAN-bron, de externe bestemming en het exacte adrespaar dat het IPsec-beleid beschermt. Doe dat voordat je een regel aanpast, want de tuple laat zien welke classificatie of NAT-regel had moeten matchen.

Zoek daarna de regel die daadwerkelijk matchte, niet die je bedoelde. Op beide platforms wordt NAT in een bepaalde volgorde geëvalueerd, en een eerdere regel kan winnen voordat jouw uitzondering wordt bekeken. Een uitzondering die er goed uitziet maar verliest van een andere regel levert het verwachte pakket nooit aan het beschermingsbeleid. Het symptoom is identiek aan een ontbrekende uitzondering, daarom moet de regelvolgorde worden gelezen voordat de configuratie verandert.

ASA identity NAT is een regel, geen omzeiling

Op de ASA is identity NAT een NAT-regel waarvan het vertaalde adres gelijk is aan het originele. De regel wordt gekozen als elke andere en installeert nog steeds een vertaalentry, dus het pakket slaat de NAT-verwerking niet over. Wat verandert, is dat de adressen op de lijn gelijk blijven, en dat is wat het IPsec-beleid nodig heeft.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

De interfaces van de regel en de route-lookup-instelling moeten passen bij het doorstuurontwerp. Een regel die het adres correct afbeeldt maar op het verkeerde interfacepaar wordt toegepast, wordt niet voor jouw flow gekozen. Route-lookup bepaalt of het vertaalde pakket wordt gerouteerd of de oorspronkelijke bestemming wordt gebruikt, en dat bepaalt of retourverkeer via de tunnel terugkomt.

Beheerstoegang tot de ASA zelf is een apart geval. Gebruik je identity NAT voor beheerverkeer, dan geldt de release-specifieke route-lookup-eis, en een brede uitzondering die uit een VPN-voorbeeld is gekopieerd lost SSH niet op.

Een deny in de IOS NAT-ACL betekent hier niet geselecteerd

Op IOS wordt internet-NAT aangestuurd door een bronlijst, en die ACL is een classificatie, geen filter. Een permit-regel selecteert verkeer voor vertaling; een deny-regel betekent dat het pakket hier niet is geselecteerd. Die deny is geen opdracht om het pakket te laten vallen zoals een deny in een interface-ACL.

Niet geselecteerd hier is ook smaller dan nergens vertaald. Een andere NAT-regel, een andere interface of een route-map kan de flow nog steeds vertalen, dus de hele NAT-tabel moet worden gelezen. Het pakket heeft ook nog een route, een overeenkomende crypto-ACL en toestemming op de werkelijke toegangscontrole-grenzen nodig.

Een minimale IOS-opzet zet de deny boven de permit in dezelfde lijst en wijst de overload-regel naar die lijst. De crypto-ACL beschermt dan hetzelfde paar dat de deny van vertaling uitsluit.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Een testbare vraag voor beide modellen

Beide modellen beantwoorden dezelfde vraag: welke regel matchte deze flow, en welke adressen verlieten de interface? Leg vast op de buiteninterface en vergelijk het bronadres voor en na de gateway. Controleer daarna het beeld van de peer op de tunnel, want de SA kan omhoog staan terwijl de beschermde flow elders wordt vertaald.

Op de ASA toon je nat detail en de vertaaltabel; op IOS toon je ip nat translations en de bijbehorende ACL-tellers. Een regel die nooit toeneemt is nooit geselecteerd, en dat wijst op volgorde, interface of richting en niet op de crypto-configuratie.

Waar de configuratie meestal fout gaat

De gebruikelijke fouten zijn mechanisch. De deny staat onder de permit en matcht nooit. De classificatie wordt in de verkeerde richting toegepast, zodat de retourflow wordt vertaald. De identity-regel dekt de juiste adressen maar het verkeerde interfacepaar. De crypto-ACL beschermt een subnet dat niet meer overeenkomt met wat de NAT-regel presenteert.

Noteer het originele en het gepresenteerde adrespaar naast de regeleigenaar, zodat de volgende engineer ziet waarom een classificatie vertaling weigert terwijl de firewall de toepassing toestaat. Bewaar dat in het wijzigingsticket, niet in een persoonlijke notitie. Draai de flow daarna opnieuw na elke NAT-wijziging, want de regelvolgorde is deel van de configuratie ook als de tekst van de regel ongewijzigd is. Een tunnel die omhoog komt is geen bewijs dat de adressen het hebben overleefd; alleen het vastgelegde pakket en het gedecapsuleerde beeld van de peer zijn dat.