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

De configuratiestappen zijn vergeleken met de bewaarde helpteksten voor SFOS 22 en 23, niet getest op een firewall. Beide helpversies bevatten nog steeds de migratiewaarschuwing voor SFOS 20.0 MR1: SFOS 20.0 MR1 en latere versies maken geen SSL Site-to-Site-verbinding met SFOS 18.5 of ouder, of met UTM 9. Deze waarschuwing is geen volledige compatibiliteitsmatrix voor alle latere builds. Controleer vóór een upgrade de specifieke combinatie; breng bij een getroffen verbinding beide Sophos Firewalls naar compatibele, ondersteunde versies of plan IPsec of een RED-tunnel. UTM 9 kan niet eenvoudig met een SFOS-upgrade worden bijgewerkt.

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. Importeer een extern certificaat met de private sleutel onder Certificates > Certificates; upload bij een externe certificaatketen ook de intermediate- en root-CA’s. 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.

Deze toestemming is alleen op de serverfirewall nodig. De clientfirewall bouwt de tunnel uitgaand op; activeer daar dus niet uit voorzorg SSL VPN voor WAN in Device Access.

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 dat niet conflicteert met een ander privé-IP-adres.
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.

Zonder Use static virtual IP address wijst de firewall de client automatisch een adres toe uit het leasebereik in SSL VPN global settings. Vul bij een vaste toewijzing het gekozen adres in bij Static peer IP; dit is het virtuele tunneladres van de client, niet het LAN van het filiaal.

De helpteksten vermelden maximaal 1024 hosts voor zowel Local networks als Remote networks. Ze leggen hier niet uit hoe netwerkobjecten worden geteld ten opzichte van afzonderlijke IP-adressen. Daaruit volgt geen algemene limiet voor de subnetgrootte en evenmin dat het opsplitsen van dezelfde netwerken een oplossing is. Controleer bij een configuratie dicht bij deze limiet de objectselectie en het opslaan op de specifieke build en verduidelijk de telmethode vóór de productiewijziging.

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, een sterk tijdelijk wachtwoord ingevoerd en bevestigd en vervolgens op Download geklikt. 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.
Op Choose file klikken en 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. Voer dan de goedgekeurde proxyserver en de werkelijke luisterpoort in. Activeer Proxy requires authentication alleen als die proxy aanmelding vereist; gebruik daarvoor de toegewezen proxygebruikersnaam en het bijbehorende wachtwoord. Neem geen poort aan en wijzig geen globale proxyinstellingen als workaround.
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.

Het wachtwoord voor de import van het versleutelde .apc-bestand ontsleutelt het bestand; het is niet het proxywachtwoord. Override peer hostname verwijst naar de servertegenpartij, niet naar de proxy. Houd beide wachtwoorden vertrouwelijk en neem ze niet op in screenshots, logs of tickets. Open na het opslaan de clientvermelding opnieuw en vergelijk proxyserver, poort, authenticatieoptie en tegenpartij met de goedgekeurde waarden zonder geheimen bloot te leggen; controleer daarna tunnel en applicatieverkeer zoals hieronder beschreven.

Voor XML-API-automatisering tonen de bewaarde Add/Edit-voorbeelden voor SFOS 22 en 23 ProxyServer, ProxyPort en ProxyAuthentication alleen bij HttpProxyServer = Enable, en Username en Password alleen bij ingeschakelde proxyauthenticatie. FilePassword hoort bij ServerConfigurationFile; PeerHost/HostName is een afzonderlijke tak. De tabel markeert proxyserver en poort als verplicht, terwijl het voorbeeld ze voorwaardelijk toont, en noemt voor proxyauthenticatie de standaardwaarde OFF, maar de toegestane waarden Disable/Enable. Leid hieruit geen serializer of geldig verzoek af: als de opname van velden of de waarderepresentatie onduidelijk is, voer de automatisering niet uit, gebruik het ondersteunde UI-pad en verduidelijk het schema voor de specifieke build met Sophos Support.

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.

Deze twee regels omvatten de nieuwe verbinding die het filiaal start en het stateful retourverkeer; voor deze flow zijn geen twee extra spiegelregels nodig. Neem de zones niet over uit een IPsec-handleiding. In Log Viewer of Packet Capture moet de testflow op de firewall van het filiaal van LAN naar de SSL-VPN-tunnel lopen en op de serverfirewall van de SSL-VPN-tunnel naar LAN. Als de waargenomen zone, Out interface of Rule ID afwijkt, corrigeer dan eerst routing en regelmatch in plaats van de regel naar Any te verbreden.

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.

Failover en rollback plannen

Een SSL Site-to-Site-tunnel maakt geen deel uit van een IPsec-failovergroep. Het .apc-bestand geeft de client de geëxporteerde serververbinding. Een FQDN of meerdere WAN-paden zorgen op zichzelf niet voor naadloze redundantie: bij een WAN-wissel wordt de bestaande sessie verbroken en moet de client de geconfigureerde server via het nieuwe pad opnieuw bereiken. Gebruik route-based IPsec als automatische tunnelfailover over meerdere gedefinieerde verbindingen nodig is.

Houd voor een eenvoudige WAN-failovertest de actieve server-FQDN via het reservepad opvraagbaar en bereikbaar; bovenliggende NAT en port forwarding moeten daar hetzelfde SSL-VPN-protocol en dezelfde poort aanbieden. Controleer daarna of de client opnieuw verbindt en of toegestaan én geblokkeerd gebruikersverkeer nog volgens het ontwerp wordt verwerkt. Ook hier is alleen een groene tunnel geen acceptatiecriterium.

Leg vóór de wijziging de vorige globale SSL-VPN-waarden, Device Access-toestemmingen, server- en clientvermeldingen, regels en het laatst werkende .apc-bestand vast. Schakel voor de rollback eerst de nieuwe regels en verbindingen uit, herstel de vorige globale waarden en Device Access-instellingen en importeer het oude .apc-bestand op de client. Verwijder nieuwe objecten pas nadat tunnel, positieve test en negatieve test weer werken.

Selecteer vóór een geautoriseerde verwijdering onder Site-to-site VPN > SSL VPN de exacte opgeslagen verbindingsnaam, firewall en rol Client of Server, controleer afhankelijke tegenpartijen en regels in productie en bewaar de werkende export en het herstelpad. De bewaarde XML-Delete-pagina’s voor SFOS 22 en 23 markeren Name als optioneel, maar bevatten geen voorbeeld van een Delete-verzoek. Dit staat geen verwijdering zonder doel of met een brede scope toe en maakt client- en serveroperaties niet onderling uitwisselbaar. Voer bij onduidelijke identiteit of een onduidelijk schema geen XML-verwijdering uit: behoud het ondersteunde UI-pad en vraag buildspecifieke verduidelijking. Controleer na de verwijdering de operatiespecifieke respons en de werkelijke toestand van de exacte doelvermelding; controleer ook de overige productieverbindingen en hun toegestane en geblokkeerde verkeer opnieuw.

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: Vanaf SFOS 20.0 kunnen FQDN-hosts en -groepen worden gebruikt als Local networks en Remote networks. Vergelijk na een DNS-wijziging eerst het op de firewall opgeloste adres met het verwachte IP-adres en controleer de geselecteerde objecten, route en één applicatieflow. Het beschikbare bewijs bevestigt niet dat het verbreken en opnieuw verbinden van een SSL Site-to-Site-tunnel deze adressen vernieuwt; onderbreek een werkende tunnel niet alleen om een DNS-vernieuwing af te dwingen. Leg bij een verouderde route de build, naamomzetting, route en logs vast voor verder onderzoek. Verwar de FQDN van een doelobject niet met de server-FQDN: als die laatste niet kan worden opgelost, kan dat het opbouwen van de tunnel zelf verhinderen.
Client bereikt de server alleen via een proxy: Use HTTP proxy server gebruiken met de vrijgegeven proxywaarden; geen willekeurige proxygegevens als algemene workaround invoeren.
Uitval na een migratie, met een tegenpartij op SFOS 18.5 of ouder of UTM 9: controleer eerst de versiecombinatie aan de hand van de bovenstaande waarschuwing voor SFOS 20.0 MR1 voordat poort of certificaat wordt gewijzigd. Een getroffen verbinding vereist compatibele tegenpartijen of een geplande oplossing met IPsec of RED.

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.