Site-to-Site RED tussen twee Sophos Firewalls configureren

Een Site-to-Site RED-tunnel verbindt twee Sophos Firewalls rechtstreeks met elkaar zonder dat op een locatie een SD-RED-appliance nodig is. Eén firewall werkt als Firewall RED server en accepteert de verbinding. De andere werkt als Firewall RED client en bouwt de tunnel naar de server op.

Deze actuele SFOS 22-procedure mag niet worden verward met een RED-bedrijfsmodus zoals Standard/Unified of Standard/Split. Die modi horen bij een fysieke SD-RED. Voor een firewall-naar-firewall-ontwerp worden in plaats daarvan op beide firewalls RED-interfaces, statische routes en passende firewallregels geconfigureerd.

⚠️ Voor de wijziging zijn op beide firewalls een actuele back-up, onafhankelijke beheertoegang en een gedocumenteerde herstelroute nodig. Het openbare adres van de Firewall RED server moet indien mogelijk niet via NAT worden vertaald, omdat deze vertaling inkomende RED-verbindingen kan verstoren.

De procedure in acht stappen

1. Rollen, RED-IP’s, locatienetwerken en een bereikbaar serveradres plannen.
2. Op beide firewalls de RED provisioning service inschakelen en het RED-besturingspad toestaan.
3. Op de centrale locatie de interface Firewall RED server aanmaken.
4. Het gegenereerde provisioningbestand veilig naar de andere locatie overbrengen.
5. In de vestiging de interface Firewall RED client aanmaken en het bestand importeren.
6. Aan beide zijden een statische route naar het externe LAN toevoegen, met het RED-IP van de peer als gateway en zonder een interface te selecteren.
7. Het dataverkeer op beide firewalls met specifieke gelogde regels toestaan; geen gekoppelde NAT-regel maken.
8. Tunnel, route, regelmatch en echt bidirectioneel verkeer afzonderlijk controleren.

Een groene RED-interface bevestigt alleen dat de tunnel is opgebouwd. Dit bewijst nog niet dat routing, firewallregels en de retourroute werken.

Planning en ontwerp

Wanneer Site-to-Site RED past

Site-to-Site RED is een eenvoudige manier om twee Sophos Firewalls te verbinden. RED-provisioning neemt een deel van de klassieke VPN-onderhandeling over, terwijl de externe LAN-netwerken gewone routing en firewallregels blijven gebruiken.

Voor nieuwe ontwerpen moet nog steeds bewust worden gekozen tussen RED en Site-to-Site IPsec. IPsec biedt meer opties voor profielen, routing, interoperabiliteit en redundantie. Site-to-Site RED is aantrekkelijk wanneer beide eindpunten Sophos Firewalls zijn en een eenvoudige, Sophos-specifieke tunnel volstaat.

Een fysieke SD-RED wordt geconfigureerd met Sophos SD-RED configureren en problemen oplossen. De RED-bedrijfsmodi gelden niet voor de hier beschreven firewall-naar-firewall-tunnel.

De voorbeeldtopologie plannen

Het volgende voorbeeld gebruikt bewust documentatieadressen. Ze worden volledig vervangen door de echte netwerken en adressen van beide locaties:

• Centrale locatie, rol Firewall RED server: openbaar adres 198.51.100.10, LAN 10.10.0.0/16
• Vestiging, rol Firewall RED client: openbaar adres 203.0.113.20, LAN 10.20.0.0/16
• RED-IP van de centrale locatie: 10.255.100.1
• RED-IP van de vestiging: 10.255.100.2

De twee RED-IP’s vormen het adrespaar tussen de firewalls. Ze mogen niet conflicteren met een locatie-LAN of een ander interface- of VPN-netwerk. De client-firewall moet het openbare IP-adres of de FQDN van de server betrouwbaar kunnen bereiken.

Het voorbeeld gebruikt 255.255.255.252 (/30) als RED netmask. Dit kleine transitnet bevat precies het benodigde adrespaar. Kies je een ander vrij transitnet, vervang dan beide RED-IP’s en het masker consequent. RED lost overlappende locatie-LAN’s niet op; bepaal eerst het adres- of NAT-ontwerp.

Sophos beschrijft RED-interfaces expliciet als veilige, versleutelde tunnels. Bij de registratie van de RED provisioning service gebruikt SFOS de registratiegegevens om een certificaat voor veilige RED-communicatie te genereren. Daarom kies je in de gedocumenteerde firewall-to-firewall-procedure geen PSK of certificaat handmatig in de interface: de server genereert een Provisioning file met configuratiegegevens voor de client. Draag dit bestand uitsluitend via een beveiligd kanaal over. Zie RED tunnels and provisioning en RED.

De tunnel en het datapad configureren

De Firewall RED server aanmaken

Eerst wordt de server aangemaakt op de firewall met een stabiel bereikbaar openbaar adres:

1. Onder System services > RED de RED provisioning service inschakelen.
2. Network > Interfaces openen.
3. Add interface > Add RED selecteren.
4. Bij Branch name bijvoorbeeld RED-HQ-Branch invoeren.
5. Type instellen op Firewall RED server.
6. Tunnel ID op Automatic laten staan.
7. 10.255.100.1 als RED IP invoeren.
8. 255.255.255.252 als RED netmask invoeren.
9. Een bewust gekozen zone toewijzen; in het voorbeeld RED-S2S.
10. Tunnel compression en MTU eerst ongewijzigd laten en opslaan.
11. Onder Network > Interfaces via het menu Download provisioning file kiezen.

Het provisioningbestand hoort bij deze tunnel en moet als gevoelig configuratiebestand worden behandeld. Het wordt via een beveiligd kanaal naar de vestiging overgebracht en blijft na de import niet in een algemeen toegankelijke download- of gedeelde map staan.

De zone beïnvloedt later de matches van regels en Device Access. LAN is mogelijk, maar een aparte zone vormt bij meerdere locaties meestal een duidelijkere beveiligingsgrens. Zones en interfaces op Sophos Firewall configureren legt de algemene samenhang uit.

Automatic voorkomt dat een Tunnel ID per ongeluk opnieuw wordt gebruikt. Bij een verplichte handmatige waarde mag deze volgens Sophos op geen van beide apparaten in gebruik zijn. In de gedocumenteerde clientprocedure voer je geen tweede Tunnel ID in; het provisioningbestand van de server levert de koppeling. Tunnel compression kan op trage verbindingen de doorvoer verbeteren, maar kost verwerking; wijzig dit alleen na een reproduceerbare voor-/nameting. Test een kleinere MTU uitsluitend bij aangetoonde fragmentatie of Path MTU-problemen.

De Firewall RED client aanmaken

Op de andere locatie wordt de client aangemaakt met het door de server gegenereerde bestand:

1. Ook hier onder System services > RED de RED provisioning service inschakelen.
2. Onder Network > Interfaces > Add interface > Add RED een nieuwe interface maken.
3. Als Branch name bijvoorbeeld RED-Branch-HQ gebruiken.
4. Type instellen op Firewall RED client.
5. Bij Firewall IP/hostname het openbare adres of de FQDN van de server invoeren.
6. Onder Provisioning file het bestand van de server-firewall selecteren.
7. 10.255.100.2 als RED IP invoeren.
8. Ook 255.255.255.252 als RED netmask invoeren.
9. RED-S2S toewijzen, Tunnel compression en MTU ongewijzigd laten en opslaan.

Als de client de server alleen via een vertaald of wisselend adres kan bereiken, moeten DNS, upstream NAT en de retourroute extra zorgvuldig worden getest. Sophos adviseert de server waar mogelijk zonder NAT rechtstreeks bereikbaar te maken.

De actuele Sophos-procedure voor Site-to-Site RED bevestigt de rollen, het bestand en het advies om de server niet met NAT te vertalen. De client start de uitgaande verbinding; de vestiging heeft dus geen gelijkwaardige inkomende publicatie nodig.

Statische routes zonder interface toevoegen

Na het opbouwen kent de tunnel de LAN-netwerken achter de firewalls niet automatisch. Aan beide zijden wordt een IPv4-unicastroute gemaakt:

• Centrale locatie: bestemming 10.20.0.0/16, gateway 10.255.100.2
• Vestiging: bestemming 10.10.0.0/16, gateway 10.255.100.1

De beslissende RED-uitzondering is dat voor deze twee routes geen interface wordt geselecteerd. De firewall verzendt ARP-verzoeken om de bereikbare RED-interface voor het adres van de peer te bepalen. Later toch een interface selecteren kan dit mechanisme verstoren en is geen verbetering.

De route wordt aangemaakt onder Routing > Static routes > IPv4 unicast route > Add. Administrative Distance en Metric worden bewust gekozen in overeenstemming met het overige routingontwerp. Een statische route op Sophos Firewall configureren en testen legt de algemene veldlogica en de controle met Route Lookup uit.

De RED-service en firewallregels beperken

Eerst moet de lokale RED-service de verbinding accepteren. Schakel onder Administration > Device access RED alleen in voor de werkelijke aankomstzone. Zijn openbare bronadressen stabiel, maak dan onder Local service ACL exception rule > Add een specifieke Accept-regel met Source zone, Source Network / Host, de WAN-interface als Destination host en Services: RED. Gewone firewallregels regelen lokale services niet. Zie Sophos Device access en Device Access en Local Service ACL.

Maak daarna onder Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule voor een flow vanuit de centrale: centraal bronzone LAN, bron 10.10.0.0/16, doelzone RED-S2S, doel 10.20.0.0/16; vestiging bronzone RED-S2S, bron 10.10.0.0/16, doelzone LAN, doel 10.20.0.0/16. Beperk Services tot wat nodig is.

Voeg voor flows vanuit de vestiging het omgekeerde paar toe. Zet Log firewall traffic aan, controleer de regelpositie en laat Create linked NAT rule uit. Behoud echte bronadressen en volledige retourroutes; overschrijf geen bewuste NAT-uitzondering zonder controle. Sophos Firewall-regels begrijpen en configureren geeft details.

Validatie, troubleshooting en rollback

De tunnel gecontroleerd testen

De controle begint met één testflow waarvan de exacte tijd wordt vastgelegd. Eerst wordt gecontroleerd of beide RED-interfaces actief zijn en of Route Lookup voor een adres in het externe LAN het verwachte pad toont. Vervolgens moet de flow op beide firewalls de bedoelde Rule ID matchen.

Een Packet Capture op Sophos Firewall toont of het pakket aan de bronzijde de RED-interface ingaat, bij de peer aankomt en naar het doel-LAN wordt doorgestuurd. De retourroute wordt afzonderlijk getest. Alleen een ping is niet voldoende wanneer de productietoepassing TCP of UDP op andere poorten gebruikt.

Succes betekent daarom dat al deze punten tegelijk kloppen:

• De RED-interfaces zijn aan beide zijden actief.
• Route Lookup toont in beide richtingen het geplande pad.
• De verwachte firewallregel matcht op beide firewalls.
• Een echte applicatieflow werkt bidirectioneel.
• Bron- en doeladressen verschijnen zonder onbedoelde NAT.
• Na een gecontroleerde herstart werkt een nieuwe flow opnieuw; een HA-cluster vereist daarnaast een afzonderlijke failovertest.

Sophos documenteert bij HA een vertraging terwijl RED-tunnels na failover opnieuw met de Auxiliary Firewall verbinden. De duur hangt af van het aantal interfaces en andere instellingen en geldt ook voor Site-to-Site RED. Beloof dus geen onmiddellijk herstel: noteer tijdstip, interfacestatus en herverbindingstijd en test de applicatie opnieuw. Zie Add a RED interface.

Fouten systematisch afbakenen

De client bouwt de tunnel niet op: Controleer RED provisioning service, serveradres, DNS, bereikbaarheid, Device Access en het provisioningbestand dat bij de tunnel hoort. Combineer niet blind een nieuw bestand met een oude clientconfiguratie.

Het provisioningbestand wordt geweigerd: controleer of het van de actuele serverinterface komt en niet tijdens overdracht veranderde. Bewaar eerst de oude toestand; download zo nodig een nieuw bestand en maak de client tijdens onderhoud opnieuw aan.

De tunnel is actief, maar het externe LAN is niet bereikbaar: Controleer aan beide zijden het doelnetwerk en het RED-IP van de peer in de statische route. Bij deze speciale RED-route mag geen interface zijn geselecteerd. Controleer daarna regelmatch en retourroute.

Slechts één richting werkt: Meestal ontbreekt op een firewall een passende regel of route, of een locatienetwerk wordt al via een specifieker pad of een pad met hogere prioriteit bereikt. Route Lookup, Packet Capture en echt retourverkeer moeten overeenkomen.

De verbinding is instabiel: Correleer latency, packet loss, openbare bereikbaarheid van de server, NAT vóór de server en wijzigingen in het WAN-pad. Bewaar node-lokale logs voor het exacte testtijdstip. Sophos Firewall-servicelogs vinden en analyseren legt de logbestanden en supportpaden uit.

Kleine verbindingen werken maar grote overdrachten stoppen: zoek in Packet Capture naar fragmentatie en ICMP Path MTU-berichten. Test pas daarna stapsgewijs dezelfde MTU op beide interfaces. Wijzig compression en MTU nooit tegelijk.

Geen brede Any-regel, algemene WAN-vrijgave, serviceherstart of willekeurige wijziging van RED-IP’s en routes vervangt deze correlatie. Blijft de fout ondanks een correct ontwerp onduidelijk, verzamel dan back-up, SFOS-build, tijdstip, interfacestatus, routes, Rule IDs, Packet Capture en relevante logs voor Sophos Support.

Veilig terugrollen

Als de pilot mislukt, schakel eerst de regels uit en verwijder de routes, daarna de client- en ten slotte de serverinterface. Herstel Device Access/Local Service ACL en MTU- of compressionwaarden; verwijder nieuwe objecten alleen wanneer niets anders ze gebruikt.

Een bestaande beheerroute die juist deze tunnel gebruikt, wordt niet verwijderd voordat alternatieve toegang positief is getest. Na de rollback worden normale routing, eerdere regels en de bereikbaarheid van beide firewalls opnieuw gecontroleerd.

FAQ