Naar de inhoud
Avanet
Aanmelden

IPsec-route aanmaken op Sophos Firewall

Sophos Firewall

Een handmatige ipsec_route hoort bij policy-based IPsec. Deze koppelt een doelhost of doelnetwerk aan een bestaande policy-based tunnel. De route breidt Traffic Selectors echter niet uit en vervangt noch firewall- en NAT-regels, noch het retourpad op de externe peer.

Voor route-based IPsec is dit commando ongeschikt. Bij een Any-to-any-tunnel krijgt de XFRM-interface een IP-adres; statische, SD-WAN- of dynamische routes bepalen vervolgens het pad. Bij een route-based tunnel met Traffic Selectors maakt SFOS de route automatisch aan. Aan de bijbehorende XFRM-interface kunt u geen IP-adres of aangepaste routes toewijzen.

⚠️ Een te brede route of een route die aan de verkeerde tunnel is toegewezen, kan productieverkeer omleiden. Leg vóór de wijziging de beginsituatie vast en houd het exacte verwijderingscommando gereed.

Wanneer een handmatige IPsec-route geschikt is

Het typische geval is doorgestuurd verkeer waarvan het adres door DNAT of SNAT wordt gewijzigd. NAT verandert het adres, maar niet de routeringsbeslissing. Daarom kan een aanvullende route naar het externe netwerk nodig zijn.

Controleer het volgende voordat u het commando uitvoert:

  • De verbinding onder Site-to-site VPN > IPsec > IPsec connections is policy-based.
  • De lokale en externe Traffic Selectors omvatten de adressen die na NAT daadwerkelijk aan de IPsec-verwerking worden aangeboden.
  • De firewall- en NAT-regels komen overeen met het gedefinieerde testverkeer. Bij SNAT voor policy-based IPsec staat Outbound interface op Any.
  • De externe peer verwacht het zichtbare bronadres en heeft een retourroute via dezelfde tunnel.
  • Een bestaande statische of SD-WAN-route en de globale Route Precedence leiden het doel niet via een ander pad.

Een handmatige route corrigeert geen onjuist netmasker, niet-overeenkomende selector of blokkerende regel. Een site-to-site IPsec-VPN op Sophos Firewall instellen licht de tunneltypen toe.

De beginsituatie vastleggen in de Device Console

Open in WebAdmin admin > Console en kies 4. Device console. Via SSH leidt Verbinding maken met Sophos Firewall via SSH naar hetzelfde menu.

Toon eerst de bestaande handmatige IPsec-routes en de globale volgorde:

system ipsec_route show
system route_precedence show

Sla de uitvoer op, samen met de tunnelnaam, Traffic Selectors, Firewall Rule ID, NAT Rule ID en de geplande teststroom. Onder SFOS 22 behoren automatisch gegenereerde policy-based VPN-routes en handmatige ipsec_route-vermeldingen tot de categorie vpn. Deze routes zijn niet zichtbaar in de routeringstabel van WebAdmin; ip route show table 220 is daarom geen betrouwbaar tegenbewijs.

Wijzig Route Precedence niet als neventaak. Deze instelling is globaal en beïnvloedt andere verbindingen. Als zij werkelijk moet worden gewijzigd, beschrijft Route Precedence op Sophos Firewall veilig wijzigen de afzonderlijke procedure met herstel op basis van de oorspronkelijke waarden.

De route aanmaken met een gecontroleerd NAT-voorbeeld

Sophos documenteert deze nauwkeurig afgebakende toepassing:

  • Een policy-based tunnel HO_to_Branch verbindt het lokale netwerk 192.168.2.0/24 met het externe netwerk 192.168.3.0/24.
  • De werkelijke lokale server 172.16.16.10 valt buiten de lokale selector.
  • De externe peer benadert deze als 192.168.2.1. Dit vervangende adres behoort tot de lokale selector en is in het voorbeeld het adres van de LAN-interface van de firewall.
Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Vervang het netwerk, de adressen en de tunnelnaam door uw eigen waarden. Het vervangende adres moet overeenkomen met de lokale Phase 2-selectie; het externe doelnetwerk moet door de bestaande tunnel worden gedekt.

1. Het externe netwerk aan de tunnel toewijzen

Voer dit commando uit in de Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Voor net verwacht SFOS het volledige masker in decimale puntnotatie. Gebruik het kleinst mogelijke doelbereik dat de toepassing vereist. Het bijbehorende terugrolcommando is:

system ipsec_route del net 192.168.3.0/255.255.255.0

Het verwijderingscommando bevat geen tunnelnaam. Controleer daarom vóór het verwijderen met system ipsec_route show of het doel eenduidig is. Verwijder dubbelzinnige vermeldingen niet uitsluitend op basis van een vermoeden.

Voor één doelhost ondersteunt de console de volgende vorm:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Een hostroute is specifieker, maar alleen juist wanneer precies die host het doel is en de Traffic Selectors overeenkomen.

2. DNAT en reflexieve SNAT configureren

  1. Maak onder Rules and policies > NAT rules > Add NAT rule > New NAT rule een DNAT-regel aan. Original source is 192.168.3.0/24, Translated source blijft Original, Original destination is 192.168.2.1 en Translated destination is 172.16.16.10.
  2. Activeer Create reflexive rule.
  3. Open de aangemaakte regel Reflexive_NAT#_<DNAT_rule_name>. Selecteer voor Translated source een IP-hostobject met 192.168.2.1. Maak het object aan onder Hosts and services > IP host > Add. Sophos kan in deze reflexieve regel niet rechtstreeks naar een interface vertalen.
  4. Controleer de volgorde, status en logging van beide NAT-regels en de bijbehorende firewallregel.

Voeg geen brede MASQ-regel toe en sta niet tevens toe dat de werkelijke server met zijn onvertaalde adres door de tunnel gaat. NAT op Sophos Firewall begrijpen legt matching en regelvolgorde uit.

Het gegevenspad valideren

Een groene tunnel en een ping bewijzen noch de NAT-vertaling, noch het retourpad. Definieer voor de validatie een echte toepassingsstroom, bijvoorbeeld TCP van de externe client naar de gepubliceerde serverservice.

  1. Voer system ipsec_route show opnieuw uit. Het doelnetwerk moet precies één keer aan de bedoelde tunnel zijn toegewezen.
  2. Maak een enkele gecontroleerde verbinding van 192.168.3.0/24 met 192.168.2.1 op de toegestane dienst.
  3. Filter Log viewer op Source, Destination en Firewall Rule ID. In de detailweergave toont src_trans_ip het werkelijk vertaalde bronadres betrouwbaarder dan de samenvattingsweergave.
  4. Open Monitor & analyze > Diagnostics > Packet capture en filter op de client, het vervangende adres en de werkelijke server. Rule ID en NAT ID moeten overeenkomen met de gedocumenteerde regels; de inkomende en uitgaande interfaces moeten het bedoelde pad tonen.
  5. Controleer op de externe peer of antwoorden van 192.168.2.1 worden verwacht en via dezelfde tunnel worden teruggestuurd.
  6. Test een naastgelegen, niet-geautoriseerde host of service. Deze negatieve test moet blijven mislukken en toont aan dat route en regels niet te breed zijn.

Alleen een actieve SA of oplopende bytetellers volstaan niet. Raadpleeg voor een volledig onderzoek Problemen met Sophos Firewall IPsec-VPN oplossen; zie voor regel- en captureanalyse Een firewallregel testen met Log Viewer, Policy Test en Packet Capture.

Wijzigingen volledig terugrollen

Beëindig eerst alle nieuwe testsessies. Herstel DNAT en reflexieve SNAT afzonderlijk naar hun gedocumenteerde eerdere toestand; een latere wijziging van de DNAT-regel verwijdert de reflexieve regel niet automatisch.

Verwijder vervolgens alleen de nieuw aangelegde route:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Verwijder het nieuwe IP-hostobject pas wanneer Object usage geen verwijzing meer toont. Herhaal vervolgens de oorspronkelijke controlestroom en de negatieve test. De eerder vastgelegde Route Precedence moet ongewijzigd blijven.

Als alleen de route per ongeluk is verwijderd, herstelt het opgeslagen add-commando de exacte vermelding:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Variant: remote clients bereiken een virtueel adres

Een virtueel bestemmingsadres kan interne serveradressen voor de externe peer verbergen. Dit scenario mag niet worden verward met het bovenstaande voorbeeld van policy-based NAT: de gedocumenteerde variant gebruikt route-based IPsec met Any-to-any-subnets, XFRM-interfaces met een toegewezen adres en gewone routes. Hiervoor wordt geen handmatige ipsec_route aangemaakt.

In het voorbeeld bevindt het netwerk 192.168.2.0/24 zich achter Firewall 1; remote clients achter Firewall 2 komen uit 192.168.3.0/24. Ze bereiken de servers 172.16.16.2 en 172.16.16.3 via het virtuele adres 10.10.10.1. Dit adres is een DNAT-bestemmingsadres, niet het XFRM-gatewayadres. Alle waarden moeten worden vervangen door objecten die bij de eigen omgeving passen.

  1. Stel in de IPsec connections op beide firewalls Connection type in op Route-based (Tunnel interface) en Local subnet en Remote subnets op Any. Firewall 1 gebruikt in het voorbeeld Respond only, Firewall 2 Initiate the connection. Open onder Network > Interfaces de blauwe balk bij de betreffende Listening interface, selecteer de XFRM-interface, voer het geplande IP-adres ervan in en sla dit op. De procedure voor site-to-site IPsec legt de basisconfiguratie van de tunnel uit.
  2. Beperk de firewallregels tot de daadwerkelijke applicatiedienst: op Firewall 2 van LAN naar VPN met bron 192.168.3.0/24 en de benodigde bestemmingen 192.168.2.0/24 respectievelijk 10.10.10.1; op Firewall 1 van VPN naar de daadwerkelijke serverzone met dezelfde externe bron en de benodigde bestemmingsobjecten 192.168.2.0/24 respectievelijk 10.10.10.1. De voorbeeldwaarde Any voor de bestemmingszone is geen aanbeveling voor een permanente toestemmingsregel.
  3. Routeer op Firewall 2 onder Routing > SD-WAN routes > IPv4 > Add de bron 192.168.3.0/24 en de benodigde bestemmingen 192.168.2.0/24 respectievelijk 10.10.10.1 via een gateway op de lokale XFRM-interface. Selecteer of maak onder Link selection settings > Primary and backup gateways de passende Primary gateway aan. Voeg op Firewall 1 het retourpad toe met bronnen 192.168.2.0/24 respectievelijk 10.10.10.1 en bestemming 192.168.3.0/24 via de XFRM-gateway van die firewall. Statische of dynamische routes zijn ook mogelijk.
  4. Route only through specified gateways voorkomt een alternatief pad door verkeer te laten vallen wanneer de tunnel niet beschikbaar is. Het voorbeeld schakelt dit op Firewall 2 in en biedt het op Firewall 1 als optie aan; het gewenste gedrag bij uitval moet aan beide kanten bewust worden vastgelegd. Administration > Device access > Ping/Ping6 > VPN heeft betrekking op ping naar lokale firewalldiensten, niet op het toestaan van een doorgestuurde serverdienst.
  5. Maak op Firewall 1 onder Rules and policies > NAT rules > Add NAT rule > New NAT rule de DNAT-regel aan: Original source 192.168.3.0/24, Translated source Original, Original destination 10.10.10.1, Translated destination een serverlijstobject met 172.16.16.2 en 172.16.16.3, Load balancing method Round-robin. Sta alleen de benodigde dienst toe; de lijst is bedoeld voor meerdere geschikte backendservers, niet voor willekeurige hosts.

Genereer voor de validatie meerdere nieuwe applicatieverbindingen naar het virtuele adres en controleer in Packet Capture en aan de hand van Rule ID en NAT ID de gekozen backends, het XFRM-pad en de antwoorden. Een ping alleen bevestigt noch DNAT, noch de applicatie, noch de verdeling. Maak vooraf een back-up van routes, regels en objecten; verwijder bij het terugdraaien alleen de elementen die voor deze variant nieuw zijn aangemaakt, na controle van de afhankelijkheden, of herstel de oorspronkelijke waarden. Er is hier geen ipsec_route om te verwijderen. De volgende foutcontroles blijven daarom onderscheid maken tussen beide tunneltypen.

Veelvoorkomende fouten systematisch isoleren

De route bestaat, maar het verkeer gaat naar WAN

Controleer system ipsec_route show, Route Precedence en concurrerende SD-WAN-routes. Onder SFOS 22 bewijst het ontbreken van een vermelding in de routeringstabel van WebAdmin of in tabel 220 niet dat de IPsec-route ontbreekt. In Route Precedence heeft vpn alleen voor verkeer naar de WAN-zone voorrang op static; controleer daarom ook de zones en het werkelijke pad naar de bestemming.

De tunnel is actief, maar NAT wordt niet toegepast

Vergelijk originele en vertaalde adressen met de Traffic Selectors. Bij policy-based SNAT moet Outbound interface Any zijn. Controleer vervolgens Firewall Rule ID, NAT ID en src_trans_ip in plaats van alleen de tunnelstatus.

Met Any gebruikt de firewall de Translated source van de overeenkomende SNAT-regel, ook wanneer Override source translation (SNAT) voor specifieke uitgaande interfaces is ingeschakeld. Een regel die bij Outbound interface alleen bepaalde WAN-poorten vermeldt, waaronder de gebruikelijke standaard-SNAT-regel, matcht dit policy-based IPsec-verkeer niet. De NAT-uitleg in het artikel over site-to-site IPsec licht dit samenspel toe; dit is geen reden om overrides overal te wijzigen. Genereer na een gerichte regelcorrectie een nieuwe gecontroleerde applicatiestroom en controleer NAT ID, src_trans_ip, de selectors en het retourpad opnieuw, zoals bij de validatie van het datapad hierboven.

Het uitgaande pad werkt, maar het antwoord ontbreekt

De externe peer moet het vertaalde adres kennen en het verkeer via dezelfde tunnel terugsturen. Controleer de Traffic Selector, firewallregel en retourroute van de peer. Een afwijkend retourpad kan niet met een bredere lokale ipsec_route worden gecorrigeerd.

Door het systeem gegenereerd verkeer of DHCP wordt beïnvloed

Authenticatie-, DNS- en DHCP-verzoeken die door de firewall zelf worden gegenereerd, volgen een afzonderlijk proces. Een algemene uitspraak dat systeemverkeer geen handmatige IPsec-route nodig heeft, zou echter onjuist zijn: bij policy-based IPsec schrijft de authenticatiehandleiding voor SFOS 22.0 en 23.0 uitdrukkelijk een IPsec-route voor als het verzoek door de gekozen Route Precedence niet in de tunnel terechtkomt. Eerst moeten het bronadres, sys-traffic-nat, de Traffic Selectors en het retourpad kloppen; pas daarna wordt alleen de benodigde bestemming aan de bestaande policy-based tunnel gekoppeld. De validatie gebeurt met een echt authenticatieverzoek en Packet Capture; het terugdraaien gebeurt afzonderlijk met de passende opdracht system ipsec_route del host of del net, na controle van de vermelding.

De volledige procedure voor policy-based en route-based authenticatie staat onder SD-WAN-routing voor antwoordpakketten en systeemverkeer. Daar worden ook de tegenstrijdigheden tussen de beschreven NAT-adresrollen en de opdrachtvoorbeelden toegelicht. Breng geen wijzigingen in de productieomgeving aan zolang het bronadres niet duidelijk is en gebruik met name niet het adres van de AD-server als vertaalde bron. Voor route-based IPsec gelden XFRM-routes, niet ipsec_route; DHCP-relay blijft een afzonderlijk proces. Hieruit volgt noch een algemene wijziging van de globale Route Precedence, noch een garantie dat het werkt.

Na de SFOS 22-upgrade ontbreekt een dynamische aankondiging

Onder SFOS 22 zijn policy-based VPN-routes geen gewone kernelroutes. Als OSPF of BGP deze eerder via redistribute kernel aankondigde, legt Waarom redistribute kernel na een SFOS 22-upgrade geen IPsec-routes meer aankondigt dit afzonderlijke migratieprobleem uit.