IPsec-route aanmaken op Sophos Firewall

Normaal gesproken herkent de Sophos Firewall zelf via welke IPsec-tunnel een doellocatie bereikbaar is. Bij een klassieke policy-based IPsec-tunnel maken lokale en externe netwerken deel uit van de tunnelconfiguratie. Bij route-based IPsec wordt verkeer daarentegen via XFRM-interfaces, statische routes, SD-WAN-routes of dynamische routing in de tunnel geleid.

Een handmatige IPsec-route is daarom geen standaard voor elke tunnel. Het is een hulpmiddel voor bepaalde policy-based scenario’s, vooral wanneer doorgestuurd verkeer met NAT of een speciale toewijzing aan de tunnel moet werken. Als een dergelijke route verkeerd wordt ingesteld, kan verkeer in de verkeerde tunnel terechtkomen of kan een bestaande verbinding moeilijker te volgen zijn.

Voor nieuwe site-to-site tunnels is het eerst passend om Sophos Firewall Site-to-Site IPsec VPN instellen te gebruiken. Voor algemeen IPsec-probleemoplossing is Sophos Firewall IPsec VPN Troubleshooting geschikt. Als het gaat om route-based VPN’s, XFRM en interfaceplanning, helpt Sophos Firewall Zones en Interfaces configureren.

Wanneer een IPsec-route zinvol is

Een IPsec-route is vooral relevant wanneer een policy-based IPsec-tunnel weliswaar bestaat, maar het verwachte verkeer niet correct aan de tunnel wordt toegewezen.

Typische gevallen:

• Een host of netwerk moet specifiek via een bepaalde policy-based tunnel lopen.
• Er zijn meerdere tunnels, overlappende doellocaties of historisch gegroeide VPN-configuraties.
• Verkeer wordt vertaald via DNAT of SNAT en moet daarna aan een bestaande IPsec-tunnel worden toegewezen.
• Na een upgrade naar SFOS 22 moet worden gecontroleerd of oude policy-based uitzonderingen nog naar verwachting werken.
• Route Lookup, Log Viewer of Packet Capture tonen dat verkeer richting WAN of een verkeerd pad gaat.

Niet elk van deze gevallen wordt opgelost door ipsec_route. Eerst moeten firewallregels, NAT-regels, routevoorrang, lokale gateways en retourroutes worden gecontroleerd.

Policy-based, route-based en SFOS 22

Het belangrijkste verschil:

• Policy-based IPsec: Sophos Firewall voert IPsec-lookups op de achtergrond uit lokale/externe netwerken in de IPsec-verbinding, firewallregels, indien nodig ipsec_route
• Route-based IPsec: Verkeer wordt naar de tunnelinterface gerouteerd XFRM-interface, statische route, SD-WAN-route of dynamische routing.

Voor nieuwe of grotere site-to-site verbindingen is route-based IPsec vaak overzichtelijker, omdat routingwijzigingen niet elke keer de tunnelselectoren veranderen. Voor eenvoudige site-to-site verbindingen of bestaande omgevingen blijft policy-based IPsec echter relevant.

SFOS 22 heeft op meerdere punten aan het IPsec-gedrag gewerkt. In de SFOS-22.0-MR1-release-opmerkingen zijn meerdere opgeloste problemen rond policy-based IPsec, ipsec_route, SD-WAN, SNAT en route lookup gedocumenteerd. Voor beheerders betekent dit: Na een upgrade moeten policy-based uitzonderingen gericht worden getest, vooral als NAT, MPLS, SD-WAN of handmatige IPsec-routes betrokken zijn.

Vereisten

Voor een wijziging moeten deze punten duidelijk zijn:

• Toegang tot de Device Console, bijvoorbeeld via SSH.
• Naam van de IPsec-tunnel.
• Doelhost of doelnetwerk dat via de tunnel moet worden bereikt.
• Actieve of correct geconfigureerde IPsec-verbinding.
• Passende firewallregels voor de verwachte richting.
• Duidelijkheid of NAT betrokken is.
• Huidige status van de bestaande IPsec-routes is gedocumenteerd.

Als de consoletoegang nog niet is ingesteld, legt Sophos Firewall verbinden via SSH uit hoe je een SSH-verbinding met de firewall maakt en de Device Console opent.

⚠️ Een verkeerde IPsec-route kan productief verkeer verstoren. Voor de wijziging moeten tunnelnaam, doelnetwerk, NAT, retourpad en bestaande routes gedocumenteerd zijn.

Voor de wijziging controleren

Een IPsec-route moet niet als eerste stap worden ingesteld. Deze volgorde is zinvol:

1. Tunnelstatus controleren: IPsec-verbinding is actief en de verwachte netwerken zijn onderhandeld.
2. Firewallregels controleren: Source zone, Destination zone, Source, Destination, Service en Logging passen.
3. NAT controleren: Het is duidelijk of originele IP-adressen of vertaalde adressen door de tunnel moeten gaan.
4. Routevoorrang controleren: Statische, SD-WAN en VPN-routes worden in de verwachte volgorde geëvalueerd. Als meerdere routingtypes concurreren, helpt Sophos Firewall Routevoorrang veilig wijzigen.
5. Tegenpartij controleren: De tegenpartij kent retourpad en verwachte bronadres.
6. Packet Capture gebruiken: Controleren of verkeer aankomt, waar het naartoe wordt geleid en of antwoorden terugkomen.

Voor de algemene regelcontrole is Firewallregel testen met Log Viewer, Policy Test en Packet Capture geschikt. Voor NAT-grondbeginselen is NAT op Sophos Firewall begrijpen passend.

Bestaande IPsec-routes weergeven

De commando’s worden uitgevoerd in de Device Console, niet in de Advanced Shell.

system ipsec_route show

De uitvoer moet voor elke wijziging worden gedocumenteerd. Zo kun je later zien of een route nieuw is toegevoegd en of deze weer moet worden verwijderd.

Daarnaast kan bij de analyse de IPsec-routingtabel relevant zijn:

ip route show table 220

Deze controle vindt plaats in de Advanced Shell en is meer bedoeld voor probleemoplossing. Voor normale wijzigingen aan ipsec_route blijft de Device Console de juiste plek.

IPsec-route voor een host aanmaken

Als slechts één enkele host via een bepaalde tunnel bereikbaar moet zijn, gebruik je host.

Syntax:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Voorbeeld:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Daarna moet je niet alleen Ping testen, maar ook het daadwerkelijke applicatieverkeer controleren. Een ICMP-test kan werken, terwijl TCP, NAT of retourpad nog steeds verkeerd zijn.

IPsec-route voor een netwerk aanmaken

Als een compleet netwerk via de tunnel bereikbaar moet zijn, gebruik je net.

Syntax:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Voorbeeld:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Bij netwerkroutes is bijzondere voorzichtigheid geboden. Een te groot netwerk kan meer verkeer in de tunnel trekken dan gepland. Bij overlappende netwerken moet vooraf duidelijk zijn welke kant welke adressen ziet en of NAT wordt gebruikt.

IPsec-route verwijderen

Als de route niet meer nodig is of verkeerd is ingesteld, kan deze weer worden verwijderd.

Host-route verwijderen:

system ipsec_route del host <host-ip>

Netwerkroute verwijderen:

system ipsec_route del net <network>/<netmask>

Daarna de lijst opnieuw controleren:

system ipsec_route show

Als de route productief verkeer heeft beïnvloed, moet je de betreffende verbinding na het verwijderen opnieuw testen en de Log Viewer-inzichten vergelijken.

NAT en policy-based IPsec

NAT is bij IPsec niet per se verkeerd. Het moet echter goed gepland zijn, omdat NAT het adres verandert dat de tegenpartij ziet.

Sophos onderscheidt bij IPsec onder andere deze gevallen:

• NAT direct in de IPsec-configuratie, bijvoorbeeld bij overlappende netwerken.
• Zelfstandige NAT-regels onder Rules and policies > NAT rules.
• ipsec_route voor doorgestuurd verkeer, wanneer vertaald verkeer aan een policy-based tunnel moet worden toegewezen.
• sys-traffic-nat voor systeemgegenereerd verkeer van de firewall zelf.

Een NAT-regel verandert de routeringsbeslissing van de firewall niet automatisch. Als een bestaande policy-based tunnel met DNAT/SNAT voor extra hosts wordt gebruikt, is nog steeds een passende IPsec Route naar het externe netwerk nodig. Bij reflexieve SNAT-regels moet het vertaalde bronadres als IP-hostobject bestaan; er kan niet zomaar direct naar een interface worden vertaald.

Belangrijk is de richting: Als policy-based IPsec-verkeer via SNAT moet worden vertaald, moet de passende SNAT-regel met Outbound interface op Any werken. Als de regel in plaats daarvan op specifieke WAN-interfaces is gericht, wordt deze niet toegepast op policy-based IPsec-verkeer. Precies zulke details leiden in de praktijk tot tunnels die groen zijn, maar geen verwacht gebruikersverkeer transporteren.

Systeemgegenereerd verkeer is een bijzonder geval

ipsec_route lost niet elk verkeersprobleem op zichzelf op. Voor doorgestuurd client- of serververkeer kan het commando direct relevant zijn. Systeemgegenereerd verkeer van de firewall zelf, zoals authenticatieverzoeken of DHCP-gerelateerde gevallen, heeft daarnaast de juiste source-NAT- en routeringslogica nodig.

Zonder gerichte configuratie gebruikt systeemgegenereerd verkeer normaal gesproken een gateway uit Network > WAN link manager. Een groene IPsec-tunnel is daarom niet genoeg om firewall-eigen verzoeken automatisch de tunnel in te sturen. DHCP Relay moet bovendien apart worden beoordeeld: bij policy-based IPsec moet bij DHCP Relay specifiek de optie Relay through IPsec worden geactiveerd. Bij route-based VPN’s is deze optie niet nodig; daar wordt DHCP-verkeer als normaal verkeer via statische, SD-WAN- of dynamische routes naar de andere kant geleid, mits lokale en externe subnetten op Any staan en er passende routes aan beide kanten bestaan.

Praktisch betekent dit:

• Client- of serververkeer door de firewall kan een ipsec_route-onderwerp zijn.
• Bij policy-based IPsec kunnen firewall-eigen verzoeken een combinatie van ipsec_route, sys-traffic-nat en passende lokale of externe subnetten nodig hebben.
• Bij route-based IPsec lopen zulke gevallen eerder via SD-WAN-routes naar de XFRM-interface en sys-traffic-nat.
• Je moet niet proberen elk systeemverkeerprobleem algemeen met ipsec_route op te lossen.

Voor systeemgegenereerd verkeer en SD-WAN-context is SD-WAN Routing voor Reply Packets en System Traffic passend.

Wijziging testen

Na het aanmaken of verwijderen van een IPsec-route moet het betreffende verkeer gericht worden getest.

Praktische procedure:

1. Testcase definiëren: Source, Destination, Service, richting en verwachte tunnel.
2. Firewallregel-logboekregistratie voor de betreffende regel activeren.
3. system ipsec_route show documenteren.
4. Testverkeer precies één keer genereren.
5. Log Viewer filteren op Source, Destination en Firewallregel.
6. Packet Capture uitvoeren met een strakke filter.
7. Controleren of bytes in ipsec statusall in beide richtingen stijgen.
8. Tegenpartij controleren op retourroute, NAT en lokale firewall.

Als grotere overdrachten blijven hangen, hoewel routing en NAT correct lijken, moet je ook MTU en MSS bij VPN-problemen controleren.

Typische fouten

• Tunnel groen, geen verkeer: vaak ontbreekt een regel, NAT, retourroute of IPsec-toewijzing. Log Viewer, Packet Capture en ipsec statusall controleren.
• Verkeer gaat richting WAN: routevoorrang of IPsec-toewijzing klopt niet. Route Lookup, SD-WAN-routes en ipsec_route show controleren.
• SNAT werkt niet bij policy-based IPsec: de SNAT-regel heeft vermoedelijk het verkeerde Outbound Interface. SNAT-regel op Any controleren.
• Een host werkt, een netwerk niet: netmasker, object of Traffic Selector klopt niet. Lokale en externe netwerken vergelijken.
• Na SFOS 22-upgrade ander gedrag: een oude uitzondering met policy-based IPsec, NAT of SD-WAN kan betrokken zijn. Release Notes, testcase en tegenpartij controleren.
• Firewall-eigen verkeer gaat niet door de tunnel: systeemverkeer wordt anders gerouteerd. SD-WAN, routevoorrang en sys-traffic-nat controleren.

Checklist

Voor de wijziging:

• Tunnelnaam en tegenpartij gedocumenteerd.
• Doelhost of doelnetwerk eenduidig.
• Firewallregels en NAT-regels gecontroleerd.
• Routevoorrang en SD-WAN-context gecontroleerd.
• Bestaande IPsec-routes veiliggesteld.
• Onderhoudsvenster of gecontroleerd testtijdstip gepland.

Na de wijziging:

• system ipsec_route show opnieuw gecontroleerd.
• Log Viewer toont de verwachte regel.
• Packet Capture toont het verwachte pad.
• Tegenpartij ziet het verwachte bronadres.
• Retourpad werkt.
• Wijziging en reden gedocumenteerd.

FAQ