Sophos Firewall SSL VPN Remote Access instellen

SSL VPN blijft op Sophos Firewall een belangrijke manier voor remote access, vooral wanneer gebruikers vanuit hotels, gast-WLAN’s, mobiele netwerken of restrictieve externe netwerken werken. Het is echter niet alleen belangrijk of de tunnel wordt opgebouwd. Het is cruciaal of de firewall de toegang goed beperkt, of DNS werkt, of MFA van toepassing is en of de firewallregels het verkeer vanuit de VPN-zone gecontroleerd toestaan.

Dit artikel beschrijft de firewallconfiguratie van SSL VPN Remote Access op Sophos Firewall. Voor de clientinstallatie zijn de volgende artikelen geschikt: Sophos SSL VPN met Sophos Connect op Windows instellen, Sophos SSL VPN met Sophos Connect op macOS instellen, Sophos SSL VPN op iPhone en iPad instellen en Sophos SSL VPN op Android instellen.

Voor de fundamentele beslissing tussen IPsec, SSL VPN, mobiele clients en ZTNA is eerst Sophos Connect of SSL VPN: Welke Remote-Access-oplossing past? geschikt.

Welke SSL-VPN-artikel past?

SSL VPN bestaat uit firewallconfiguratie, portal, client, authenticatie en latere foutenanalyse. Afhankelijk van de taak is er een andere startpunt geschikt:

Deze scheiding is belangrijk: een gebruikersprobleem in het VPN Portal, een verouderd .ovpn-profiel, een ontbrekende firewallregel en een DNS-probleem zien er voor de gebruiker vaak hetzelfde uit. Voor de analyse moeten deze niveaus gescheiden worden.

Doelbeeld

Een goede SSL-VPN-opbouw bestaat uit meerdere bouwstenen:

1. Gebruikers of groepen zijn in het juiste SSL-VPN-beleid gemachtigd.
2. De globale SSL-VPN-instellingen definiëren gateway, poort, certificaat, lease-bereik, DNS en cryptografie.
3. Het VPN Portal is alleen zo breed bereikbaar als nodig en beschermd met MFA.
4. Firewallregels staan verkeer vanuit de VPN-zone alleen naar de benodigde doelen toe.
5. Split Tunnel of Full Tunnel is bewust gekozen.
6. Clients importeren een actueel .ovpn-profiel.
7. Logs, Packet Capture en ondersteuningsgegevens kunnen in geval van fouten worden geëvalueerd.

Veel SSL-VPN-problemen ontstaan omdat alleen de clientdownload wordt gedocumenteerd. In de praktijk moet men echter portal, authenticatie, SSL-VPN-beleid, firewallregel, DNS en NAT samen bekijken.

⚠️ SSL VPN is een openbaar toegankelijke toegangspunt. MFA en sterke wachtwoorden zijn belangrijk, maar vervangen geen beperking via Device access, nauwe gebruikersgroepen, actuele profielen, logging en regelmatige reviews.

Vereisten

Voor de configuratie moeten deze punten duidelijk zijn:

• Sophos Firewall met actuele SFOS-versie.
• Openbare bereikbaarheid van de firewall of een voorgeschakelde port forwarding.
• FQDN of openbaar IP-adres voor de VPN-toegang.
• Certificaat voor VPN Portal en SSL VPN, idealiter passend bij de FQDN.
• Gebruikers of groepen voor Remote Access.
• Authenticatieserver: lokaal, Active Directory, RADIUS of Microsoft Entra ID.
• MFA/OTP-concept voor VPN Portal en Remote Access.
• Interne doelnetwerken, DNS-servers en zoekdomein.
• Beslissing voor Split Tunnel of Full Tunnel.
• Firewallregels voor verkeer vanuit de VPN-zone.
• Proces voor clientupdate en herverdeling van het .ovpn-bestand.

Als Microsoft Entra ID SSO gebruikt moet worden, moet de authenticatie correct worden voorbereid voordat de VPN-configuratie wordt gedownload. De procedure staat in Microsoft Entra ID SSO voor Sophos Connect en VPN Portal instellen.

1. Lokale objecten voorbereiden

Eerst moeten de doelnetwerken als hosts of netwerkobjecten bestaan:

Hosts and services > IP host

Typische objecten:

Men moet niet zomaar complete interne netwerkgebieden vrijgeven als alleen enkele servers of subnetten nodig zijn. Hoe nauwer de objecten zijn gedefinieerd, hoe eenvoudiger de firewallregel later wordt.

2. Globale SSL-VPN-instellingen controleren

De globale instellingen gelden voor alle Remote-Access-SSL-VPN-beleidsregels:

Remote access VPN > SSL VPN > SSL VPN global settings

Protocol en poort

SSL VPN kan afhankelijk van de configuratie TCP of UDP gebruiken. UDP is vaak efficiënter, TCP kan in restrictieve netwerken beter functioneren. De beslissing moet worden getest met de netwerken waaruit gebruikers daadwerkelijk werken.

Bij de poort moet men overlappingen vermijden:

• SSL VPN standaardpoort is vaak 8443.
• VPN Portal gebruikt in actuele SFOS-versies standaard 443.
• WAF-regels en SSL VPN mogen zich op hetzelfde WAN-IP niet met dezelfde poort en hetzelfde protocol overlappen.
• Als SSL VPN en VPN Portal dezelfde poort gebruiken, kunnen inlogbeveiligingsfuncties niet zoals verwacht werken.

Als WAF, VPN Portal, User Portal en SSL VPN op hetzelfde WAN-IP worden uitgevoerd, moet men poort, protocol en certificaat bewust documenteren. Voor WAF-grondslagen is Sophos Firewall WAF instellen en typische fouten vermijden geschikt.

Certificaat en Override Hostname

Onder SSL server certificate moet een certificaat worden gebruikt dat bij de openbare FQDN past. Een certificaatfout in het VPN Portal of in het SSL-VPN-profiel leidt later tot onnodige ondersteuningsgevallen.

Onder Override hostname bepaalt men welke hostnaam of welk IP-adres clients in het .ovpn-profiel gebruiken. Dit is vooral belangrijk bij:

• meerdere WAN-IP-adressen,
• voorgeschakelde router,
• NAT of port forwarding voor de firewall,
• dynamische WAN-IP met DDNS,
• gescheiden FQDN’s voor WebAdmin, VPN Portal en SSL VPN.

Als het veld leeg blijft, kunnen meerdere interface-adressen in het profiel terechtkomen. Dit kan werken, maar is in productieve omgevingen vaak minder eenduidig dan een duidelijke FQDN.

Lease-bereik

Sophos Firewall kent SSL-VPN-clients adressen toe uit het geconfigureerde lease-bereik. Dit bereik mag niet overlappen met interne netwerken, statische routes, site-to-site VPN’s of typische thuisnetwerkgebieden.

Men moet vooral veelvoorkomende subnetten vermijden zoals:

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

Als het lease-bereik overlapt met het thuisnetwerk van een gebruiker, verbindt de tunnel soms succesvol, maar blijven interne doelen onbereikbaar. Dit lijkt dan op een firewallregelprobleem, maar is een routeringsprobleem op de endpoint.

Voor firewallregels moet men de systeemhosts ##ALL_SSLVPN_RW en bij IPv6 ##ALL_SSLVPN_RW6 gebruiken, niet handmatig nagebouwde hosts met oude lease-bereiken.

Statische SSL-VPN-IP-adressen en Key Lifetime

Statische SSL-VPN-IP-adressen kunnen in sommige gevallen nuttig zijn, bijvoorbeeld voor admin-toegangen, streng gelogde speciale toegangen of legacy-toepassingen met IP-gebaseerde vrijgave. Als standaard voor alle gebruikers zijn ze echter niet geschikt. Hoe meer statische toewijzingen er zijn, hoe moeilijker het beheer, de foutenanalyse en latere migraties worden.

In de lijst met bekende problemen is een specifiek geval gedocumenteerd: Bij SSL VPN met lokale authenticatie en statisch toegewezen SSL-VPN-IP kan de herauthenticatie na het verstrijken van de Key Lifetime mislukken. De firewall kan het al toegewezen lease-adres als conflict beschouwen. Gebruikers moeten zich dan handmatig opnieuw verbinden, hoewel de tunnel eerder werkte. Een typische Key Lifetime-waarde is 18000 seconden.

Als een gebruiker zich na enkele uren herhaaldelijk opnieuw moet aanmelden, moet men daarom niet alleen MFA, clientversie en firewallregel controleren. Daarnaast moeten deze punten in de analyse worden opgenomen:

• Wordt lokale authenticatie voor SSL VPN gebruikt?
• Heeft de gebruiker een statisch SSL-VPN-IP-adres?
• Treedt het probleem ongeveer op na het verstrijken van de Key Lifetime?
• Werkt dezelfde gebruiker met dynamische IP-toewijzing stabieler?
• Is een statisch IP echt nodig of volstaat een regel over gebruikersgroep, SSL-VPN-systeemhost en logging?

Als pragmatische tegenmaatregelen noemt Sophos twee richtingen: Key Lifetime zo plannen dat deze de normale werkdag dekt, of dynamische IP-toewijzing gebruiken. In veel omgevingen is dynamische toewijzing schoner, omdat firewallregels toch over VPN-zone, gebruikersgroep, doelobjecten en de SSL-VPN-systeemhosts moeten worden gecontroleerd.

DNS en Domeinnaam

Voor interne naamresolutie worden in de globale SSL-VPN-instellingen DNS-servers en optioneel een domeinnaam ingesteld. In Active Directory-omgevingen is dit meestal een interne DNS-server of domeincontroller.

Daarnaast moet onder Administration > Device access DNS vanuit de VPN-zone worden toegestaan als de firewall zelf als DNS-resolver in het VPN-ontwerp wordt gebruikt.

Als DNS in de tunnel niet werkt, moet men afzonderlijk testen:

• Is het doel per IP-adres bereikbaar?
• Wordt de interne DNS-server door de firewallregel toegestaan?
• Ontvangt de client de juiste zoekdomein?
• Gebruikt de client echt het actuele .ovpn-profiel?
• Grijpt lokale DNS- of DoH-configuratie van de endpoint ertussen?

3. SSL-VPN-beleid aanmaken

Het beleid maakt men aan onder:

Remote access VPN > SSL VPN

Stappen:

1. Add selecteren.
2. Configure manually gebruiken.
3. Naam geven, bijvoorbeeld SSLVPN-Remote-Users.
4. Onder Policy members de gemachtigde gebruikers of groepen selecteren.
5. Split Tunnel of Full Tunnel instellen.
6. Bij Split Tunnel de Permitted network resources selecteren.
7. Optioneel Disconnect idle clients configureren.
8. Opslaan en vervolgens met een testgebruiker controleren.

Belangrijk: Als gebruikers of groepen in een nieuwer SSL-VPN-beleid worden opgenomen die al in een ouder SSL-VPN-beleid zijn opgenomen, verwijdert Sophos Firewall deze toewijzing uit het eerdere beleid. Daarom moet men beleidsoverschrijdingen vermijden en per gebruikersgroep duidelijk definiëren welk beleid van toepassing is.

4. Split Tunnel of Full Tunnel beslissen

Split Tunnel

Bij Split Tunnel loopt alleen verkeer naar de toegestane interne bronnen door de VPN-tunnel. Internetverkeer van de gebruiker gaat verder direct via het lokale netwerk van de gebruiker.

Split Tunnel is vaak geschikt voor:

• Toegang tot enkele interne toepassingen,
• Lagere firewallbelasting,
• Betere gebruikersprestaties,
• Kleinere externe locaties en mobiele gebruikers.

De beveiliging hangt dan sterker af van de endpoint, de lokale netwerkomgeving en de vrijgegeven interne bronnen.

Full Tunnel

Bij Full Tunnel wordt al het verkeer van de remote gebruiker via de firewall geleid. In Sophos Firewall komt dit overeen met de optie Use as default gateway.

Full Tunnel is meer geschikt als:

• Internetverkeer centraal gecontroleerd moet worden,
• Web Protection, DNS Protection of logging voor VPN-gebruikers van toepassing moeten zijn,
• Gebruikers vanuit onveilige netwerken werken,
• Compliance centrale evaluatie vereist.

Bij Full Tunnel volstaat het SSL-VPN-beleid alleen niet. Men heeft daarnaast firewallregels en NAT/SNAT nodig voor internetverkeer vanuit de VPN-zone. Bovendien moet men prestaties, bandbreedte, webfiltering en logging vooraf testen.

5. Firewallregels voor VPN-zone aanmaken

Het opbouwen van de tunnel betekent nog niet dat verkeer is toegestaan. Voor toegang tot interne bronnen heeft men een passende firewallregel nodig:

Rules and policies > Firewall rules

Aanbevolen regel voor Split Tunnel:

Voor Full Tunnel is er daarnaast een regel nodig van VPN naar WAN of Any, afhankelijk van het ontwerp. De Source Networks moeten nog steeds de SSL-VPN-systeemhosts zijn. Daarna moet worden gecontroleerd of er een passende SNAT-regel bestaat.

Als er een verbinding is, maar geen toegang werkt, moet men eerst de Log Viewer controleren. Voor de methodiek is Firewallregel testen met Log Viewer, Policy Test en Packet Capture geschikt.

6. VPN Portal en Device Access beveiligen

Gebruikers downloaden Sophos Connect en het .ovpn-bestand meestal via het VPN Portal:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Minimaal controleren:

• VPN Portal poort en certificaat.
• VPN Portal Authentication Methods.
• MFA voor VPN Portal en Remote Access.
• Device Access voor VPN Portal alleen in benodigde zones.
• Device Access voor SSL VPN op de WAN-zone alleen als extern nodig.
• Geen permanent open User Portal op WAN als het niet nodig is.

Voor het versterken van lokale firewallservices is Device Access en Local Service ACL op Sophos Firewall geschikt. Voor MFA-grondslagen is MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren geschikt.

Het VPN Portal is alleen zinvol voor gebruikers als zij of hun groepen in een passend Remote-Access-beleid zijn opgenomen. Als de beleidskoppeling ontbreekt, ziet de gebruiker de benodigde configuratiedownloads niet.

Als VPN Portal of SSL VPN op de WAN-zone moet worden toegestaan, moet dit bewust worden gedocumenteerd. In veel omgevingen is het niet voldoende om de dienst wereldwijd te openen en op MFA te vertrouwen. Waar mogelijk moeten vaste bronnetwerken, landbeperking, Threat Feeds, logcontrole of een voorgeschakeld Remote-Access-ontwerp worden gecontroleerd.

7. Clientprofiel distribueren

Na de beleid- en portalconfiguratie wordt het .ovpn-bestand gedistribueerd. Dit kan via het VPN Portal of gecontroleerd door het adminproces gebeuren.

Belangrijk:

• Na wijzigingen aan gateway, poort, certificaat, DNS, lease-bereik, beleid of authenticatie moet het profiel opnieuw worden geladen.
• Een Sophos-Connect-update vervangt geen oud .ovpn-profiel.
• Profielnamen moeten eenduidig zijn.
• Oude profielen moeten bij locatieverandering, gatewayverandering of gebruikersverandering worden verwijderd.
• Windows, macOS, iOS, Android en Linux gebruiken soms verschillende clientpaden.

Voor clientupdates en versiebeheer is Sophos Connect Clientversie controleren en veilig bijwerken geschikt.

Na de configuratie testen

Met een testgebruiker moet men niet alleen controleren of Sophos Connect Connected aangeeft.

Testlijst:

• Gebruiker ziet in het VPN Portal de Sophos Connect-download en de SSL-VPN-configuratie.
• .ovpn-bestand kan worden geïmporteerd.
• MFA wordt zoals verwacht gevraagd.
• Client ontvangt een adres uit het SSL-VPN-lease-bereik.
• Route naar de toegestane interne netwerken verschijnt op de endpoint.
• Interne DNS-namen worden opgelost.
• Toegang tot toegestane servers werkt.
• Niet-toegestane netwerken blijven geblokkeerd.
• Log Viewer toont de juiste firewallregel.
• Packet Capture toont verkeer over een tun-interface, indien nodig.
• Bij Full Tunnel werkt ook internettoegang en SNAT.

Als de test alleen met een admingebruiker wordt gedaan, worden groeps- en beleidsfouten gemakkelijk over het hoofd gezien. Beter is een normale pilotgebruiker uit de doelgroep.

Acceptatietest per scenario

Voor een brede uitrol moet men minimaal deze testgevallen goed documenteren:

Voor productieve omgevingen moet elke test een tijdstip, een gebruiker, een clientplatform en een concreet doel bevatten. Uitspraken zoals “VPN werkt” of “VPN werkt niet” zijn voor latere ondersteuningsgevallen te vaag.

Logs en bewijzen verzamelen

Bij SSL-VPN-problemen moet men eerst vaststellen of de fout bij het inloggen, bij het opbouwen van de tunnel of bij de toegang tot interne doelen ligt. Deze scheiding bespaart tijd, omdat anders authenticatie, clientprofiel, routering en firewallregels door elkaar worden gecontroleerd.

Voor een reproduceerbare testgeval moeten deze gegevens worden genoteerd:

Daarna moet men de controle in deze volgorde uitvoeren:

1. Authenticatie controleren: In de Log Viewer en indien nodig in de authenticatielogs controleren of gebruiker, MFA, groep en authenticatieserver succesvol zijn. Bij Microsoft Entra ID SSO is daarnaast oauth_sso_vpn.log relevant.
2. Tunnelstatus controleren: SSL-VPN-verbinding, lease-adres en OpenVPN-status controleren. Aan de firewallzijde helpen sslvpn.log en openvpn-status*.log.
3. Firewallregel controleren: In de Log Viewer zoeken naar verkeer vanuit de VPN-zone en controleren welke regel daadwerkelijk matcht. De regel moet Log firewall traffic actief hebben.
4. Pakketstroom controleren: Als de Log Viewer niet voldoende is, met Packet Capture op bron, doel en dienst filteren. Belangrijk is of pakketten alleen Incoming zijn of ook Forwarded worden.
5. Doelzijde controleren: Als verkeer de firewall verlaat, maar er geen antwoord terugkomt, zijn terugroute, serverfirewall, lokale hostfirewall of een netwerkconflict waarschijnlijker dan het SSL-VPN-beleid.

Voor de toewijzing van de belangrijkste logbestanden is Sophos Firewall Troubleshooting: Services en Logs geschikt. Voor regelanalyse met Log Viewer, Policy Test en Packet Capture is Firewallregel testen met Log Viewer, Policy Test en Packet Capture geschikt.

Probleemoplossing

Gebruiker ziet geen SSL-VPN-configuratie in het VPN Portal

Meestal ontbreekt de beleidskoppeling. Men controleert of de gebruiker of zijn groep in het SSL-VPN-beleid onder Policy members is opgenomen. Daarnaast moeten authenticatie, MFA en VPN-portalbereikbaarheid worden gecontroleerd.

Als aanmelding en beleidskoppeling correct lijken, maar de download van het .ovpn-bestand toch ontbreekt of mislukt, moet ook het Sophos Firewall User-ID-Limit worden gecontroleerd. Dit is vooral relevant als meerdere gebruikers het portal gebruiken, maar alleen enkele downloads onverwacht mislukken.

Tunnel verbindt, maar interne systemen zijn niet bereikbaar

Eerst controleren of op de endpoint een route naar het interne doelnetwerk bestaat. Daarna in de Log Viewer zoeken naar verkeer vanuit de VPN-zone. Als er geen verkeer zichtbaar is, bereikt de client de firewall niet zoals verwacht of is het profiel verouderd.

Als verkeer zichtbaar is, maar de verkeerde regel van toepassing is, moet de regelvolgorde of de service-/doeldefinitie worden gecorrigeerd. Als er helemaal geen antwoord terugkomt, zijn routering, doelfirewall, lokale serverfirewall of een netwerkconflict waarschijnlijk.

DNS werkt niet

Men controleert of de toegang per IP-adres werkt. Als dat zo is, ligt de fout waarschijnlijk bij DNS. Daarna DNS-servers in de globale SSL-VPN-instellingen, domeinnaam, Device Access voor DNS vanuit de VPN-zone en endpoint-DNS-gedrag controleren.

Toegang werkt alleen bij sommige gebruikers

Dan zijn groepslidmaatschap, beleidskoppeling, statische SSL-VPN-IP-adressen, MFA-status of verouderde profielen waarschijnlijker dan een globale firewallfout. Ook dubbele beleidskoppelingen moeten worden gecontroleerd.

Gebruiker moet zich na enkele uren opnieuw verbinden

Als SSL VPN aanvankelijk werkt, maar na enkele uren een hernieuwde aanmelding of een handmatige heropbouw nodig is, moet men eerst tijdspatronen, authenticatie en lease-model controleren. Vooral relevant is dit bij lokale authenticatie met statisch toegewezen SSL-VPN-IP.

Praktische procedure:

1. Tijdstip van de verbinding en de onderbreking noteren.
2. Tijdstip vergelijken met de geconfigureerde Key Lifetime.
3. Controleren of de gebruiker een statisch SSL-VPN-IP-adres heeft.
4. Testen met dynamische IP-toewijzing voor een pilotgebruiker, indien operationeel mogelijk.
5. In sslvpn.log, openvpn-status*.log en Log Viewer zoeken naar authenticatie, lease-adres en hernieuwde aanmelding.
6. Als een langere Key Lifetime wordt gekozen, wijziging documenteren en niet als vervanging voor MFA of goede sessiecontrole beschouwen.

Als statische IP’s alleen worden gebruikt om firewallregels eenvoudiger te laten lijken, moet het ontwerp worden herzien. Meestal zijn groepen, duidelijk benoemde doelobjecten, nauwe diensten en logging een betere basis dan individuele gebruikers-IP-adressen.

Full Tunnel heeft geen internettoegang

Bij Use as default gateway is er een firewallregel nodig voor verkeer vanuit de VPN-zone richting internet en een passende SNAT-regel. Bovendien moeten web-, DNS- en beveiligingsbeleid zo worden gepland dat ze VPN-gebruikers niet onverwacht blokkeren.

Verbinding staat, maar grote overdrachten hangen

Als inloggen, DNS en kleine toegangen werken, maar RDP, bestandsoverdrachten, webtoepassingen of grote downloads hangen, moet men MTU en MSS controleren. Het foutbeeld past vaak bij fragmentatie, PPPoE, getunnelde verbindingen of een asymmetrisch pad, niet alleen bij SSL VPN zelf.

Voor de systematische analyse is Sophos Firewall MTU en MSS bij VPN-problemen controleren geschikt.

WAF of Portal botst met SSL VPN

Als WAF, VPN Portal, User Portal en SSL VPN op hetzelfde WAN-IP draaien, moeten poort en protocol goed gescheiden zijn. Vooral kritisch zijn gezamenlijk gebruikte combinaties van WAN-IP, poort en TCP. Bij onduidelijke drops Log Viewer en Packet Capture controleren.

Profiel is na wijziging verouderd

Na wijzigingen aan SSL-VPN-beleid, gateway, DNS, certificaat, poort of authenticatie moet het .ovpn-bestand opnieuw worden gedownload en geïmporteerd. Veel schijnbare clientproblemen zijn verouderde profielen.

Bedrijfschecklist

Voor de productieve uitrol

• FQDN en certificaat voor VPN Portal en SSL VPN gecontroleerd.
• SSL-VPN-lease-bereik overlapt niet met interne of typische thuisnetwerken.
• SSL-VPN-beleid bevat de juiste gebruikers of groepen.
• Split Tunnel of Full Tunnel is bewust gekozen.
• Toegestane netwerkbronnen zijn bij Split Tunnel nauw gedefinieerd.
• DNS-servers en domeinnaam zijn correct ingesteld.
• Firewallregel van VPN naar interne doelen bestaat en logt.
• Bij Full Tunnel bestaan internetregel en SNAT.
• Device Access voor SSL VPN en VPN Portal is bewust ingesteld.
• MFA is voor Remote Access getest.
• Testgebruiker kan profiel downloaden, importeren en interne doelen bereiken.

Voor de lopende operatie

• MFA voor VPN Portal en Remote Access afdwingen.
• VPN-groepen regelmatig controleren.
• Firewallregels voor VPN nauw houden en loggen.
• Lease-bereik voor netwerkveranderingen controleren.
• Statische SSL-VPN-IP-adressen alleen gericht gebruiken en regelmatig controleren.
• DNS en zoekdomein documenteren.
• Portal- en SSL-VPN-certificaten voor vervaldatum vernieuwen.
• Sophos Connect-versies volgen.
• Profielherverdeling na wijzigingen plannen.
• Logs op lange termijn via Syslog of Sophos Central evalueren, als traceerbaarheid belangrijk is.

Voor logbestanden en diensten is Sophos Firewall Troubleshooting: Services en Logs geschikt.

Speciale gevallen regelmatig controleren

• Statische SSL-VPN-IP-adressen zijn gerechtvaardigd en gedocumenteerd.
• Key Lifetime past bij het bedrijfsmodel en is getest met herverbinding.
• Oud .ovpn-profiel wordt na wijzigingen opnieuw verdeeld.
• VPN Portal, User Portal, WAF en SSL VPN botsen niet op hetzelfde WAN-IP met poort en protocol.
• Gebruikers met speciale rechten of admin-toegang worden apart gecontroleerd.

FAQ