Sophos Firewall SSL Site-to-Site VPN instellen

Een SSL Site-to-Site VPN verbindt de interne netwerken van twee Sophos Firewalls via een versleutelde tunnel. Anders dan bij IPsec heeft elke kant een vaste rol: de clientfirewall brengt de verbinding altijd tot stand en de serverfirewall accepteert deze.

Dit is vooral geschikt wanneer een filiaal een dynamisch openbaar IP-adres heeft of IPsec problemen ondervindt in een bovenliggend netwerk. Het hoofdkantoor met een statisch adres of een stabiele FQDN wordt de server, het filiaal wordt de client. Voor groeiende netwerken, dynamische routing, redundantie of een tegenpartij van een andere fabrikant is route-based IPsec meestal flexibeler; voor een kleine verbinding tussen twee Sophos Firewalls kan SSL Site-to-Site eenvoudiger zijn.

Deze handleiding gebruikt een concreet voorbeeld:

Hoofdkantoor, server: vpn.example.com, lokaal netwerk 10.10.0.0/24
Filiaal, client: dynamisch openbaar IP-adres, lokaal netwerk 10.20.0.0/24
Verbinding: HQ-to-Branch
SSL-VPN-poort: 8443

vpn.example.com, de objectnamen en beide netwerken zijn placeholders die door de waarden van de eigen omgeving worden vervangen. 8443 is de standaardpoort; deze blijft alleen ongewijzigd als het poortgebruik en het beveiligingsontwerp daarbij passen.

De korte procedure is: rollen en netwerken bepalen, globale SSL-VPN-waarden controleren, SSL VPN in de WAN-zone van de server toestaan, de serververbinding maken, het .apc-bestand exporteren, dit op de clientfirewall importeren en vervolgens routes, regels en echt gebruikersverkeer controleren.

⚠️ De globale SSL-VPN-instellingen worden ook gebruikt door Remote Access SSL VPN. Wijzig daarom poort, protocol, certificaat, adresbereik of cryptografie niet uitsluitend voor deze tunnel. Controleer eerst de gevolgen voor bestaande gebruikersverbindingen en profielen.

Rollen, netwerken en openbare toegang plannen

De serverfirewall is bij voorkeur de stabielere en, bij verschillende modellen, de krachtigere appliance. Als slechts één kant een statisch openbaar IP-adres heeft, hoort die kant de serverrol te krijgen. De client kan zich achter NAT bevinden of een verbinding met een dynamisch adres gebruiken, zolang deze de server kan bereiken.

Voor de configuratie moeten de volgende punten vaststaan:

openbaar IP-adres of FQDN van de serverfirewall;
protocol en poort voor SSL VPN;
lokaal netwerk van het hoofdkantoor en lokaal netwerk van het filiaal;
unieke, niet-overlappende adresbereiken;
benodigde services en toegestane verbindingsrichtingen;
retourpad aan beide kanten;
alternatieve beheerstoegang voor de change;
actuele SFOS-versies op beide firewalls.

Als de netwerken elkaar overlappen, volstaat deze standaardconfiguratie niet. Dan is een bewust vertaal- en routingontwerp nodig; in de praktijk is IPsec met geplande NAT daarvoor meestal beter geschikt.

Compatibiliteit vóór de change controleren

Sinds SFOS 20.0 MR1 gebruikt Sophos een nieuwere OpenVPN-component. SSL Site-to-Site-tunnels vanaf SFOS 20.0 MR1 maken geen verbinding met SFOS 18.5 of ouder en ook niet met UTM 9. In zo’n combinatie moeten beide Sophos Firewalls worden bijgewerkt of moet IPsec dan wel een RED-tunnel worden gebruikt.

Globale SSL-VPN-instellingen controleren

De gedeelde instellingen staan op de toekomstige serverfirewall onder:

Remote access VPN > SSL VPN > SSL VPN global settings

Voor het voorbeeld worden vooral deze waarden gecontroleerd:

Protocol: UDP is meestal de efficiëntere eerste keuze; TCP kan helpen in restrictieve netwerken.
SSL server certificate: moet geldig zijn en samen met de private sleutel en de volledige certificaatketen geïmporteerd zijn. Bij een openbare FQDN hoort het certificaat bij voorkeur bij die naam te passen.
Override hostname: vpn.example.com, als de clients precies deze FQDN moeten gebruiken.
Port: 8443, tenzij bewust een ander poortontwerp is gepland.
Assign IPv4 addresses: mag niet overlappen met de twee locatienetwerken of met andere VPN-pools.
Cryptographic settings: bestaande waarden niet wijzigen zonder compatibiliteits- en praktijktest.

Als de serverfirewall achter een bovenliggende router staat, moet deze router de gekozen poort en het protocol naar de firewall doorsturen. De FQDN verwijst dan naar het openbare adres van de router. WAF en SSL VPN mogen niet dezelfde combinatie van WAN-IP, poort en protocol gebruiken.

Als Port, Protocol, SSL server certificate of Override hostname later verandert, moet de serverconfiguratie opnieuw worden gedownload en op de clientfirewall opnieuw worden geïmporteerd. De bestaande .apc-export kent de nieuwe waarden niet.

De volledige afhankelijkheden van de globale instellingen worden uitgelegd in SSL VPN Remote Access op Sophos Firewall. Wijzigingen worden daar gepland met aandacht voor bestaande gebruikersprofielen, leasebereiken, DNS en openbaar bereikbare services.

SSL VPN voor de WAN-zone van de server toestaan

Op de serverfirewall wordt de lokale SSL-VPN-service voor de inkomende zone toegestaan:

Administration > Device access

Als de clientfirewall een dynamisch of niet zinvol te beperken openbaar adres heeft, wordt onder VPN services SSL VPN voor WAN geactiveerd. Dit staat alleen het opbouwen van de tunnel naar de firewall toe; het vervangt geen firewallregel voor gebruikersverkeer tussen de locaties.

Als de openbare bronnetwerken van de clientkant stabiel bekend zijn, blijft SSL VPN in de WAN-matrix uitgeschakeld. In plaats daarvan wordt een gerichte Accept Local Service ACL Exception aangemaakt met Source zone WAN, de bekende Source Networks/Hosts, het WAN-adres van de server als Destination host en de service SSL VPN. Een Accept-uitzondering beperkt een al actieve WAN-matrixtoegang niet. De planning wordt uitgelegd in Device Access op Sophos Firewall veilig configureren.

Serververbinding op het hoofdkantoor maken

Eerst worden op de serverfirewall beide netwerken als IP-hostobjecten aangemaakt:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Daarna wordt de serververbinding gemaakt:

Site-to-site VPN > SSL VPN openen.
In het gedeelte Server op Add klikken.
Als naam HQ-to-Branch invoeren.
Onder Local networks HQ-LAN selecteren.
Onder Remote networks Branch-LAN selecteren.
Use static virtual IP address alleen activeren als daar een gegronde reden voor is en een vrij adres buiten de globale statische en dynamische SSL-VPN-bereiken kiezen.
Opslaan met Save.

Local networks zijn vanuit het perspectief van de serverfirewall de netwerken van het hoofdkantoor. Remote networks bevinden zich achter de clientfirewall. Dit perspectief is belangrijk: als de objecten worden verwisseld, kan de tunnel groen worden terwijl routes en regels niet bij de gewenste verbinding passen.

Serverconfiguratie veilig exporteren

In de serverlijst wordt bij HQ-to-Branch Download gekozen. De export heeft de bestandsextensie .apc en bevat de verbindingsgegevens voor de clientfirewall.

Voor een veilige overdracht wordt Encrypt configuration file geactiveerd en een sterk tijdelijk wachtwoord ingesteld. Bestand en wachtwoord worden via gescheiden kanalen overgedragen. Het .apc-bestand hoort niet thuis in een openbaar ticket, een onbeveiligde chat of een permanente downloadmap.

Configuratie op de clientfirewall importeren

Op de firewall van het filiaal wordt via hetzelfde menupad geïmporteerd:

Site-to-site VPN > SSL VPN openen.
In het gedeelte Client op Add klikken.
Als naam Branch-to-HQ invoeren.
Onder Configuration file het geëxporteerde .apc-bestand selecteren.
Bij een versleutelde export het wachtwoord invoeren.
Use HTTP proxy server alleen activeren als het filiaal de server werkelijk via een expliciete HTTP-proxy bereikt.
Override peer hostname alleen instellen als het serveradres in de export niet routeerbaar of niet opvraagbaar is vanuit het clientnetwerk. In het voorbeeld blijft het veld leeg, omdat vpn.example.com al globaal wordt geëxporteerd.
Opslaan met Save en de verbinding activeren.

De status wordt groen zodra de clientfirewall de server bereikt en de tunnel is opgebouwd. Een groene status bevestigt alleen de verbinding zelf, niet de toegang tot servers, DNS of applicaties.

Routes en firewallregels controleren

De onder Local networks en Remote networks geselecteerde netwerken worden actief voor de tunnelrouting. Ze behoren tot de routingklasse static en moeten bij de overige routingconfiguratie passen. Een specifiekere statische, SD-WAN- of VPN-route kan anders tot een ander pad leiden dan verwacht. De volgorde wordt uitgelegd in Routingprioriteit op Sophos Firewall begrijpen en aanpassen.

Firewallregels voor het gebruikersverkeer worden bewust op beide firewalls gemaakt of vergeleken met bestaande regels. In het voorbeeld, waarin het filiaal verbindingen naar het hoofdkantoor initieert, zijn minimaal nodig:

op de firewall van het filiaal een strikte regel van LAN naar VPN voor Branch-LAN naar de benodigde doelen in HQ-LAN;
op de serverfirewall een passende regel van VPN naar LAN voor Branch-LAN naar deze doelen;
alleen de benodigde services, bijvoorbeeld DNS, RDP en HTTPS;
Log firewall traffic voor de acceptatietest;
geen SNAT- of MASQ-regel die het locatieverkeer zonder functionele reden wijzigt.

Als het hoofdkantoor ook nieuwe verbindingen naar het filiaal moet kunnen opbouwen, worden de omgekeerde richtingen afzonderlijk toegestaan. Een brede Any-regel is geen voltooid beveiligingsontwerp. Hoe regelpositie, Rule ID en Packet Capture samen worden gecontroleerd, laat Firewallregel testen zien.

Tunnel en gebruikersverkeer valideren

De test begint met een concrete client en een concreet doel. In het voorbeeld maakt een apparaat uit 10.20.0.0/24 verbinding met een toegestane server in 10.10.0.0/24.

Op beide firewalls de groene status en oplopende bytetellers controleren.
Het doel eerst via het IP-adres en vervolgens via de hostname testen.
Een werkelijk toegestane service zoals HTTPS of RDP openen.
In Log Viewer de verwachte Firewall Rule ID en de ongewijzigde bron- en doeladressen controleren.
Een niet-toegestane service of een niet-vrijgegeven doel testen en de drop bevestigen.
De omgekeerde richting afzonderlijk controleren als deze functioneel toegestaan moet zijn.
Na een herstart of WAN-wissel controleren of de clientfirewall de tunnel opnieuw opbouwt.

Een geslaagde ping is niet voldoende. Deze bewijst noch DNS noch de benodigde applicatieservice. Bij een intern doelsysteem moeten firewallregel, retourpad en endpointfirewall bij de test passen; Device Access is alleen relevant als een adres van de Sophos Firewall zelf wordt gepingd.

Logs bij een fout lezen

Onder Site-to-site VPN > SSL VPN > Logs kan de SSL-VPN-logging direct worden geopend. Voor een diepere controle meldt men zich aan via SSH, kiest 5. Device Management > 3. Advanced Shell en leest het actuele servicelog:

tail -n 200 /log/sslvpn.log

De opdracht wijzigt geen configuratie. Tijdstip, verbindingsnaam en server-/clientkant worden samen gedocumenteerd. Andere OpenVPN-statusbestanden kunnen afhankelijk van het aantal processen aanwezig zijn als openvpn-status0.log, openvpn-status1.log en verdere bestanden; de toewijzing wordt uitgelegd in Sophos Firewall-servicelogs.

Typische fouten gericht afbakenen

Tunnel blijft rood: openbare FQDN, DNS, port forwarding, protocol, certificaat en SSL VPN in Device Access voor de WAN-zone van de server controleren. Daarna sslvpn.log op hetzelfde tijdstip lezen.
Na een globale wijziging komt de tunnel niet meer tot stand: serverconfiguratie opnieuw exporteren en op de client opnieuw importeren. Vooral poort, protocol, certificaat en Override hostname zijn afhankelijk van de export.
Tunnel is groen, maar er stroomt geen verkeer: tunnelrouting, routingprioriteit, regels op beide firewalls, Rule ID, retourpad, NAT en endpointfirewall controleren. Daarna één afzonderlijke flow volgen met Packet Capture.
Alleen namen werken niet: toegang via IP testen, DNS-server en zoekdomein controleren en verzekeren dat de DNS-server via de tunnel bereikbaar en toegestaan is.
FQDN-hostobject verwijst nog naar het oude adres: FQDN-hosts en -groepen worden ondersteund als lokale en externe netwerken. Na een DNS-wijziging de tunnel gecontroleerd verbreken en opnieuw verbinden en daarna de route en het gebruikersverkeer naar het opnieuw opgevraagde IP-adres controleren. Ontbrekende naamomzetting is eerst een verkeers- of routingfout, niet automatisch een fout bij het opbouwen van de tunnel.
Client bereikt de server alleen via een proxy: Use HTTP proxy server gebruiken met de vrijgegeven proxywaarden; geen willekeurige proxygegevens als algemene workaround invoeren.
Eén kant gebruikt SFOS 18.5 of UTM 9: niet verder zoeken bij poort of certificaat. Met een actuele tegenpartij is deze combinatie incompatibel; beide kanten bijwerken of IPsec dan wel RED gebruiken.

Als de tunnel na een gecontroleerde test nog steeds onduidelijk blijft, worden SFOS-versie en build van beide firewalls, tijdstip met tijdzone, verbindingsnaam, sslvpn.log, Rule IDs en een korte Packet Capture veiliggesteld. Pas daarna mogen regels, netwerken of globale SSL-VPN-waarden verder worden gewijzigd.