FortiGate bakom NAT: local-gw, localid och den publika IP-adressen

En FortiGate bakom NAT kan äga 10.0.0.2 på sitt WAN-gränssnitt, medan internet presenterar den som 198.51.100.40, och båda talen är verkliga. Adressen som enheten binder till och identiteten den skickar under IKE-autentisering är separata val, gjorda i separata fält, för separata mottagare. NAT skriver om den yttre adresseringen på vägen; det skriver inte om en autentiserad identitet till det den avlägsna peer förväntar sig. De flesta fel i fas 1 i den här formen kommer av att rätt värde hamnar i fel fält.

Tre värden, tre ägare

Börja med att namnge de tre värdena och vem som äger varje. local-gw är adressen som FortiGate använder som källa för IKE på sitt externa gränssnitt, och den måste vara en adress som enheten faktiskt har. Den publika slutpunkten är NAT-enhetens adress och ägs av den som utför översättningen. IKE-identiteten är en sträng som peer jämför med sin egen konfiguration, och den behöver inte alls vara en IP-adress.

Fältnamnen ligger nära nog att locka till utbyte, och det är fällan. localid och localid-type beskriver identifiering; local-gw beskriver lokal bindning.

Ett exempel gör skillnaden konkret. På FortiGate öppnar du config vpn ipsec phase1-interface, sedan set interface "wan1" och set local-gw 10.0.0.2 — en adress som boxen äger, och det är vad som får IKE-socketen att binda korrekt. Låt local-gw stå på 0.0.0.0 och gränssnittsadressen används, vilket oftast är samma sak men mindre explicit. Sätt inte local-gw till 198.51.100.40, eftersom enheten inte äger den adressen och socketen kommer inte att binda till den. Att få två värden att se lika ut på papper är inte en konfiguration.

Steg 1: välj den identitet som peer accepterar

Nu identiteten, vilket är ett annat beslut. set localid tar värdet som peer jämför, och set localid-type berättar för FortiGate hur det ska tolkas: en adress, ett FQDN, ett användar-FQDN eller ett nyckel-ID. Med auto härleder enheten det, vanligtvis från adressen för det utgående gränssnittet, vilket är exakt det värde en NAT-enhet är på väg att ändra.

Den härledningen är anledningen till att en explicit identitet spelar roll i den här topologin. Om peer förväntar sig en adressidentitet, sätt localid-type address och localid till den publika adressen som peer kommer att se, och bekräfta sedan att peer accepterar det värdet som identitet och inte som routingmål. Om peer förväntar sig ett FQDN, använd localid-type fqdn och namnet det konfigurerades med. Verifiera vad som faktiskt skickades med diagnose vpn ike gateway list, som visar gatewayens status och de identifierare som används, inte det du tänkte skriva. Anta inte att ett identitetstyp-alternativ accepterar en godtycklig icke-lokal adress; kontrollera först releaseversionens dokumenterade semantik.

Steg 2: vidarebefordra UDP 500 och 4500 till enheten

Det tredje värdet tillhör NAT-enheten, och det är det som folk glömmer att kontrollera. Den publika slutpunkten måste vidarebefordra UDP 500 och UDP 4500 till FortiGate, eftersom NAT-T-detektering och den inkapslade ESP som följer båda är beroende av att dessa portar kommer in. Den här designen förutsätter en en-till-en-mappning; att dela en enda publik adress via portar mellan flera peer är en annan topologi med andra gränser.

Bekräfta vidarebefordran med en inspelning i stället för en förhoppning: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 visar om paket kommer in och om svar går ut.

Google Cloud VPN dokumenterar en-till-en-NAT med NAT-T som det stödda arrangemanget för en peer bakom NAT, och det är begränsningen att designa mot om den avlägsna änden är en Cloud VPN-gateway. En-till-många eller portbaserad delning är inte samma stödda topologi, och ingen mängd lokal identitetsjustering ändrar det. Om den avlägsna sidan är en annan enhet definierar dess egen dokumentation vad den accepterar som identitet och om den tolererar en översatt peer-adress. Läs det innan du ändrar ett lokalt fält, eftersom den lokala sidan inte kan förhandla en regel som den avlägsna sidan inte implementerar.

Steg 3: kontrollera vad fas 1 inte löser

NAT-traversering får tunneln upp, identitetsenighet avgör om peer accepterar den, och routning av inre prefix avgör vad som faktiskt passerar. Ett korrekt lokalt ID kan inte leverera en saknad statisk rutt eller en saknad trafikväljare.

Så verifiera i lager. get vpn ipsec tunnel details visar om tunneln är uppe och vilka väljare som förhandlades, och en avvikelse mellan det konfigurerade avlägsna subnätet och den förhandlade väljaren är ett routningsproblem i fas 2-kostym. execute vpn ike gateway clear tvingar fram en ny förhandling, så du testar den aktuella konfigurationen och inte en session som upprättades före din senaste ändring. Skicka sedan trafik till en värd i det avlägsna prefixet och bekräfta att räknarna rör sig, eftersom en tunnel som är uppe och inte släpper igenom något ser identisk ut med en fungerande tills du kontrollerar.

Håll de tre värdena på ett ställe i dina anteckningar: den lokala adressen som enheten äger, den publika slutpunkten som NAT-enheten presenterar och identitetssträngen som peer förväntar sig. De ändras av olika skäl och vid olika tidpunkter.

En omnumrering av NAT-enheten är inte skäl att röra local-gw på FortiGate, och en identitetsändring är inte skäl att omnumrera något. Att blanda de två är hur en fungerande tunnel byggs om under ett orelaterat underhållsfönster. Cloud VPN:s NAT-vägledning är referensen för den stödda topologin på den sidan.

Testet som avgör saken är tråkigt och snabbt: spela in på det externa gränssnittet, bekräfta att UDP 500 och 4500 kommer från peer, bekräfta att identiteten i IKE-utbytet stämmer med det peer var konfigurerad att förvänta sig, och bekräfta sedan att de förhandlade väljarna täcker de subnät du bryr dig om. Om den första kontrollen misslyckas är NAT-enheten den misstänkta. Om den andra misslyckas är det identitetsfälten. Om den tredje misslyckas var varken NAT eller identitet någonsin problemet.