Sophos Firewall Site-to-Site IPsec VPN instellen

Een Site-to-Site IPsec VPN verbindt twee locaties, of een Sophos Firewall met een firewall van een derde partij, via een versleutelde tunnel. In de praktijk mislukt zo’n tunnel zelden door één enkele optie in de interface. Vaker gaat het om onduidelijke netwerken, verschillende IPsec-profielen, ontbrekende firewallregels, NAT-uitzonderingen of een retourpad dat aan één kant is vergeten.

Dit artikel legt uit hoe men een Site-to-Site IPsec-tunnel op Sophos Firewall schoon opbouwt. De focus ligt op planning, uitvoering en acceptatietest. Als een bestaande tunnel al groen is maar er geen verkeer loopt, is Sophos Firewall IPsec VPN Troubleshooting het betere vervolgartikel.

Wanneer dit artikel past

Dit artikel past bij klassieke locatieverbindingen, bijvoorbeeld:

• Hoofdlocatie naar filiaal
• Sophos Firewall naar Sophos Firewall
• Sophos Firewall naar firewall van een derde partij
• Sophos Firewall naar cloud gateway wanneer geen speciale cloud-assistent wordt gebruikt
• Migratie van eenvoudige oude policy-based tunnels naar een gedocumenteerde actuele configuratie

Het gaat niet om Remote Access voor individuele gebruikers. Daarvoor passen de artikelen Sophos Connect op Sophos Firewall configureren, Sophos Connect of SSL VPN: welke Remote Access-oplossing past? en Legacy Remote Access IPsec vóór SFOS 22 MR1 migreren.

Policy-based of route-based IPsec

Voor de configuratie moet worden beslist of de tunnel policy-based of route-based wordt opgebouwd. In actuele SFOS-versies zijn deze begrippen duidelijker gescheiden dan in oudere handleidingen, die deels nog over Site-to-Site of Tunnel Interface spreken.

Voor kleine, stabiele verbindingen is policy-based IPsec vaak het snelst te begrijpen. Voor grotere of dynamische locatienetwerken is route-based IPsec meestal schoner, omdat routing en VPN-onderhandeling beter gescheiden zijn. Als meerdere netwerken, SD-WAN, BGP, OSPF of cloudnetwerken betrokken zijn, moet route-based IPsec bij voorkeur worden onderzocht.

Vereisten

Voor het instellen moet deze informatie gedocumenteerd zijn:

⚠️ Site-to-Site VPN mag niet zonder gedocumenteerd retourpad worden geïmplementeerd. Als de lokale firewall verkeer de tunnel instuurt, maar de tegenpartij geen route terug kent of NAT anders verwacht, ziet de tunnel er vaak gezond uit terwijl applicaties niet werken.

Voor de configuratie plannen

Netwerken eenduidig houden

Lokale en externe netwerken mogen elkaar niet onbedoeld overlappen. Vooral veelgebruikte standaardnetwerken zoals 192.168.0.0/24, 192.168.1.0/24 of hergebruikte filialenetwerken zijn problematisch. Als netwerken overlappen, is een bewust NAT-ontwerp nodig. Gewoon hetzelfde adresbereik aan beide kanten gebruiken en later “op de een of andere manier” vertalen, levert tunnels op die moeilijk te onderhouden zijn.

Voor nieuwe locaties loont daarom een schoon IP-adresconcept. Als VLANs of zones nog niet netjes zijn gemodelleerd, helpt Sophos Firewall zones en interfaces configureren.

IPsec-profiel afstemmen

Beide kanten moeten bij Phase 1 en Phase 2 compatibele parameters gebruiken. Daartoe behoren versleuteling, authenticatie, DH group, PFS en lifetime. Bij verbindingen met firewalls van derden is het vaak het eenvoudigst om eerst een gezamenlijk profiel schriftelijk vast te leggen en daarna beide kanten te configureren.

Als een tunnel niet opkomt, zijn NO_PROPOSAL_CHOSEN, ID-fouten of authenticatiefouten typische aanwijzingen. De gestructureerde analyse staat in Sophos Firewall IPsec VPN Troubleshooting.

Firewallregels niet vergeten

Een IPsec-tunnel geeft nog geen productieve toegang. Verkeer door de tunnel heeft nog steeds passende firewallregels nodig. Bij policy-based verbindingen zijn dat meestal regels tussen LAN en VPN of tussen eigen zones. Bij route-based designs hangt het ervan af aan welke zone de XFRM-interface of het relevante pad is toegewezen.

Voor de introductie moet Log firewall traffic in de betrokken regels worden geactiveerd. Anders ontbreekt later precies de informatie welke regel een test heeft toegestaan of geblokkeerd. De algemene controle staat in firewallregel testen met Log Viewer, Policy Test en Packet Capture.

Automatisch gemaakte regels bewust controleren

Bij het maken van een Site-to-Site IPsec-verbinding kan de optie Create firewall rule helpen om een eerste regelset aan te leggen. Dat vervangt geen security review. Sophos Firewall maakt deze regels bovenaan de firewallregellijst. In actuele SFOS-versies ontstaan daarvoor afzonderlijke regels voor inkomend en uitgaand verkeer met de prefixen Incoming en Outgoing.

Voor beheer is daarom belangrijk:

⚠️ Automatisch gemaakte firewallregels zijn een startpunt, geen afgerond security design. Vooral bij locatietunnels naar servernetwerken moet men na de eerste test services, bronnen en doelen beperken.

Bij route-based IPsec met Any-to-Any-subnetten moet men bijzonder zorgvuldig werken. Voor zulke route-based designs kunnen geen automatische firewallregels worden gemaakt. Bij dual IP-versies moeten IPv4- en IPv6-regels apart worden gepland. In deze scenario’s moeten firewallregels, XFRM-interface, routes en tests bewust handmatig worden opgebouwd.

Policy-based IPsec instellen

Policy-based IPsec is de klassieke variant voor eenvoudige Site-to-Site-verbindingen. De lokale en externe netwerken worden direct in de IPsec-verbinding gedefinieerd.

1. IPsec-profiel controleren of maken

Menu path:

Profiles > IPsec profiles

Eerst controleren of een bestaand profiel bij de tegenpartij past. Als een eigen profiel nodig is, moet het duidelijk worden benoemd, bijvoorbeeld IPsec_IKEv2_AES256_G14. De naam moet later begrijpelijk blijven wanneer meerdere tunnels en tegenpartijen bestaan.

Minimaal te documenteren:

• IKE-versie
• Phase 1 Encryption en Authentication
• DH Group
• Phase 2 Encryption en Authentication
• PFS
• Key lifetime

Bij firewalls van derden moet de tegenpartij dezelfde waarden schriftelijk bevestigen. Alleen een screenshot is vaak niet genoeg, omdat afzonderlijke velden per fabrikant anders heten.

2. IPsec-verbinding toevoegen

Menu path:

Site-to-site VPN > IPsec

Maak een nieuwe IPsec-verbinding en kies Policy-based als Connection type. Stel daarna de basisgegevens in:

• Naam van de tunnel, bijvoorbeeld branch-zurich
• Local gateway of Listening interface
• Remote Gateway als IP-adres of FQDN
• Authentication type: Preshared Key of certificaat
• Local ID en Remote ID indien nodig
• IPsec profile
• Local subnet
• Remote subnet

Voor Preshared Keys moet een sterke, unieke sleutel worden gebruikt en veilig worden gedocumenteerd. Een gedeelde oude standaardsleutel voor meerdere locaties is een onnodig operationeel risico.

3. Tunnel activeren

Bij het opslaan kan Activate on save worden ingesteld. In productieomgevingen moet dit gebeuren in een gedefinieerd onderhoudsvenster, wanneer de tegenpartij bereikbaar is en beide kanten logs kunnen controleren.

Na het opslaan toont de lijst twee relevante statussen:

• of de verbinding actief is
• of de tunnel daadwerkelijk established is

Een actieve vermelding is niet automatisch een opgebouwde tunnel. Bij meerdere lokale of externe netwerken kunnen er bovendien meerdere Security Associations zijn.

Route-based IPsec instellen

Route-based IPsec scheidt VPN-onderhandeling en routing duidelijker. Sophos Firewall maakt daarbij een XFRM-interface. Daarna bepalen statische routes, SD-WAN Routes of dynamische routing welk verkeer door de tunnel loopt.

1. Verbinding als route-based maken

Menu path:

Site-to-site VPN > IPsec

Kies bij de verbinding Route-based (Tunnel interface). De parameters voor gateway, authenticatie, IDs en IPsec-profiel moeten nog steeds bij de tegenpartij passen. Daarnaast moet duidelijk zijn welke XFRM-interface daarna ontstaat en hoe die wordt gerouteerd.

Sophos toont de gegenereerde XFRM-interface onder de gebruikte fysieke interface in:

Network > Interfaces

Afhankelijk van het design heeft de XFRM-interface een IP-adres nodig. Vooral bij Any-to-Any-designs, dual IP-versie of complexere routingscenario’s moet de interface-adressering schoon worden gepland.

Wanneer Any-to-Any wordt gebruikt, beslist niet langer alleen de Tunnel Selector welk verkeer door de tunnel gaat. Routes en firewallregels worden dan de centrale sturing. Dat is flexibel, maar ook foutgevoelig: een te brede regel kan meer verkeer toestaan dan bedoeld, een ontbrekende route kan de tunnel groen laten lijken zonder dat gebruikersverkeer loopt.

2. Routing instellen

Bij route-based VPN is de IPsec-verbinding alleen niet genoeg. Er is een route naar het externe netwerk nodig:

• statische route naar de XFRM-interface
• SD-WAN Route met passende gateway of profiel
• dynamische route via BGP of OSPF als het design daarvoor is gebouwd

Voor eenvoudige setups is een statische route vaak voldoende. Als meerdere WAN-lijnen, SLA-controles of failoverpaden worden gebruikt, is een SD-WAN Route zinvoller. De algemene context rond SD-WAN, Reply Packets en systeemgegenereerd verkeer staat in Sophos Firewall SD-WAN routing voor Reply Packets en System Traffic controleren.

3. XFRM en MTU meenemen

Route-based VPNs zijn gevoeliger voor misverstanden rond routing, MTU en MSS. Als kleine tests werken maar grotere transfers blijven hangen, moet men niet meteen het IPsec-profiel wijzigen. Eerst MTU, MSS, fragmentatie en het echte pad controleren. De passende procedure staat in Sophos Firewall MTU en MSS bij VPN-problemen controleren.

Firewallregels maken

Na de IPsec-configuratie zijn regels nodig voor productief verkeer. Zonder passende regels blijft de tunnel mogelijk groen, maar werken applicaties niet.

Menu path:

Rules and policies > Firewall rules

Typische regels:

Goede praktijk:

• Regelnaam met tunnel of locatie, bijvoorbeeld LAN_to_Branch_Zurich.
• Source en Destination zo smal mogelijk instellen.
• Services concreet definiëren.
• Logging tijdens introductie en troubleshooting activeren.
• Regelpositie controleren.
• Beschermingsfuncties bewust instellen in plaats van ze toevallig over te nemen.

Als internetverkeer van een filiaal via de centrale moet lopen, is daarnaast een bewust NAT- en securityconcept nodig. Dat is een ander design dan een eenvoudige locatieverbinding voor interne netwerken.

NAT bewust plannen

NAT is bij IPsec niet verboden, maar het moet duidelijk gemotiveerd zijn. Typische gevallen zijn overlappende netwerken, cloudvereisten of derde partijen die alleen bepaalde bronadressen accepteren.

Menu path:

Rules and policies > NAT rules

Voor een NAT-regel moeten deze vragen beantwoord zijn:

• Verwacht de tegenpartij originele IP-adressen of vertaalde adressen?
• Zijn er overlappende netwerken?
• Wordt NAT in de IPsec-verbinding opgelost of via afzonderlijke NAT-regels?
• Is de retourrichting gedocumenteerd?
• Toont Log Viewer na NAT de verwachte Source en Destination?

Voor policy-based uitzonderingen met NAT kan een handmatige IPsec Route op Sophos Firewall relevant worden. Dat is echter geen standaardstap voor elke tunnel.

Device Access en WAN-toegang

Voor inkomende IPsec-aanvragen moet de firewall IPsec-verkeer op de passende WAN-zone kunnen accepteren. Dat wordt niet via een normale LAN-to-WAN-regel opgelost, maar via de lokale services van de firewall.

Menu path:

Administration > Device access

Daar moet IPsec voor de benodigde zone zijn toegestaan. Tegelijk moet worden gecontroleerd of andere lokale services zoals WebAdmin, SSH, User Portal of VPN Portal onnodig breed bereikbaar zijn. Voor het hardenen van deze lokale services is Sophos Firewall-toegang beveiligen: Device Access correct configureren het centrale artikel.

Tunnel testen

Een goede acceptatietest controleert niet alleen de groene status. Hij controleert de daadwerkelijke datastroom.

1. Status controleren

In de WebAdmin-interface:

Site-to-site VPN > IPsec

Controleren:

• Verbinding is actief.
• Tunnelstatus is established.
• Bij meerdere netwerken zijn alle verwachte Child SAs opgebouwd.
• Geen terugkerende reconnects of fouten zichtbaar.

2. Log Viewer controleren

Menu path:

Log viewer

Testverkeer met duidelijke Source, Destination en Service genereren. Daarna in Log Viewer controleren welke firewallregel matcht en of NAT, Webfilter, IPS of andere modules het verkeer beïnvloeden.

3. Packet Capture gebruiken

Als Log Viewer niet genoeg is, moet Packet Capture met een smal filter worden gebruikt:

Diagnostics > Tools > Packet capture

Filtervoorbeeld:

host 172.16.10.25 and host 10.20.30.15

Bij VPN-troubleshooting is het belangrijk beide richtingen te controleren. Alleen uitgaande pakketten zonder antwoord wijzen meestal op een retourpad-, NAT- of tegenpartijprobleem.

4. CLI alleen gericht gebruiken

Voor diepere analyse kan via SSH de Advanced Shell worden gebruikt:

ipsec statusall

Daarbij zijn onder andere interessant:

• IKE SA established
• Child SA installed
• lokale en externe netwerken
• byte-tellers in beide richtingen
• terugkerende rekey- of disconnect-meldingen

Als SSH nog niet is voorbereid, helpt via SSH verbinden met Sophos Firewall.

Typische fouten

Checklist

Voor de change:

• Lokale en externe netwerken zijn eenduidig.
• Policy-based of route-based is bewust gekozen.
• IPsec-profiel is met de tegenpartij afgestemd.
• Preshared Key of certificaten zijn veilig gedocumenteerd.
• Firewallregels zijn gepland, inclusief richting, regelpositie, logging en services.
• Bij Create firewall rule is duidelijk welke automatisch gemaakte regels moeten worden nabewerkt.
• Bij route-based Any-to-Any zijn handmatige firewallregels en routes gepland.
• NAT is uitgesloten of bewust gedocumenteerd.
• Device Access voor IPsec is gecontroleerd.
• Onderhoudsvenster, tegenpartij en fallbackpad zijn bekend.

Na de change:

• Tunnelstatus is established.
• Log Viewer toont de verwachte firewallregel.
• Packet Capture toont heen- en retourrichting.
• Interne DNS- en applicatietoegang is getest.
• Byte-tellers stijgen in beide richtingen.
• NAT en retourpad zijn met de tegenpartij afgestemd.
• Wijziging is in de netwerkdocumentatie bijgewerkt.

Veelgestelde vragen