Sophos Firewall Bridge-VLANs controleren na SFOS 22

Bridge-interfaces op Sophos Firewall zijn handig wanneer een bestaand Layer-2-netwerk transparant moet worden voortgezet of een migratie zonder onmiddellijke IP-wijziging moet worden uitgevoerd. Met VLANs op een bridge wordt het ontwerp echter snel foutgevoelig: Er is dan forwarding tussen netwerken, verkeer naar de firewall zelf, Device Access, DNS, AD, authenticatie en vaak nog oude CLI-configuraties.

Precies op dit punt is er bij SFOS 22 een belangrijke operationele situatie. Sophos vermeldt in de huidige lijst met bekende problemen een probleem waarbij Bridge-interfaces met CLI VLAN tag configuraties in SFOS 22.0 GA en SFOS 22.0 MR1 VLAN-getagd verkeer niet correct verwerken wanneer dit verkeer van de Sophos Firewall zelf afkomstig is of op de firewall eindigt. Dit kan bijvoorbeeld Active Directory, DNS, Device Access, STAS, LDAP, RADIUS of beheerstoegang betreffen, hoewel normaal verkeer door de bridge wordt doorgestuurd.

Dit artikel is geen algemeen hoofdstuk over VLAN-grondslagen. Voor de planning van zones, interfaces, VLANs, bridges en LAGs is het eerst handig om Sophos Firewall Zones en Interfaces configureren te raadplegen. Hier richten we ons specifiek op de Bridge-VLAN-speciale situatie na SFOS 22.

Wanneer dit onderwerp relevant is

De controle is zinvol wanneer meerdere punten samenkomen:

• De firewall draait op SFOS 22.0 GA of SFOS 22.0 MR1.
• Er is een bridge-interface, bijvoorbeeld br0.
• VLANs zijn historisch gebouwd via CLI VLAN tag configuratie zoals system vlan-tag of overgenomen uit een oude configuratie.
• Diensten van de firewall zelf moeten een getagd VLAN bereiken.
• Na een upgrade werken AD, DNS, authenticatie, monitoring of beheerstoegang slechts gedeeltelijk.
• Normaal cliëntverkeer door de bridge lijkt nog steeds te werken.

Het laatste punt is belangrijk: Als de bridge nog steeds verkeer tussen netwerken doorstuurt, lijkt het probleem aanvankelijk niet op een bridge-fout. In de praktijk zoekt men dan snel op de verkeerde plek, zoals bij firewallregels, DNS, STAS of de domeincontroller.

Betrokken verkeersrichting begrijpen

Men moet drie soorten verkeer duidelijk scheiden.

Als slechts één applicatie tussen twee hosts wordt getest, herkent men de fout daarom niet zeker. De test moet bewust een dienst omvatten die op de Sophos Firewall eindigt of door de firewall wordt gegenereerd.

Typische symptomen

Mogelijke tekenen zijn:

• Gebruikersgebaseerde regels werken niet meer betrouwbaar omdat AD, STAS of LDAP niet stabiel bereikbaar zijn.
• DNS-verzoeken aan de firewall falen vanuit enkele VLANs.
• Ping of HTTPS naar lokale firewall-diensten werkt niet vanuit een VLAN, hoewel de firewallregels plausibel lijken.
• Monitoring of Syslog lijkt onvolledig wanneer de firewall een doel in een getagd VLAN moet bereiken.
• Packet Capture toont dat verkeer tussen eindsystemen zichtbaar is, maar diensten van de firewall zelf niet zoals verwacht reageren.
• Na een SFOS-22-upgrade treden de symptomen op zonder dat er bewust iets aan de switch of firewallregels is gewijzigd.

Dergelijke symptomen moeten niet onmiddellijk worden beantwoord met brede Allow-regels of Device Access-toestemmingen. Eerst moet duidelijk zijn of het interface-ontwerp zelf is beïnvloed.

Snelle afbakening voor de verbouwing

Voordat men een bridge-IP verplaatst of nieuwe VLAN-interfaces op de bridge aanmaakt, moet men de oorzaak afbakenen. Niet elk probleem na een upgrade is automatisch het SFOS-22-Bridge-VLAN-geval.

Voor DNS-problemen is het daarnaast belangrijk of cliënten de firewall als resolver gebruiken of dat de firewall zelf DNS Request Routes naar interne servers gebruikt. Het tweede geval betreft verkeer van de firewall en kan bij Bridge-VLAN-problemen anders zijn dan normaal cliëntverkeer. De basisprincipes staan in DNS Request Routes op Sophos Firewall instellen.

Als de snelle afbakening duidelijk wijst op lokale firewall-diensten of door de firewall gegenereerd verkeer, moet de verbouwing toch worden gepland. Een bridge-correctie zonder back-up, onderhoudsvenster en alternatieve toegangspad is bij productieve netwerken te riskant.

Bestaand ontwerp vastleggen

Voor wijzigingen moet men de huidige situatie documenteren. Vooral belangrijk zijn:

• Naam van de bridge-interface, bijvoorbeeld br0.
• Bridge-leden, dus betrokken fysieke interfaces, VLANs, RED-interfaces of LAGs.
• IP-adres van de bridge, indien aanwezig.
• VLAN IDs die over de bridge lopen.
• Switch-poortprofiel: Tagged VLANs, Native VLAN, Trunk of Access Port.
• Diensten die op de firewall eindigen: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Diensten die de firewall moet bereiken: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Als de opbouw uit een oude migratie stamt, moet men daarnaast controleren of VLANs via CLI-configuratie zijn ingesteld. Precies deze erfenis is vaak niet meer in gedachten als de firewall jarenlang alleen is bijgewerkt.

⚠️ Aan bridge-interfaces en VLANs moet men niet spontaan experimenteren tijdens de dagelijkse operatie. Een verkeerde wijziging kan beheerstoegang, DNS, authenticatie of hele cliëntnetwerken beïnvloeden. Voor de correctie is een back-up, een onderhoudsvenster en een alternatieve toegangspad nodig.

Workaround: VLAN-interfaces op de bridge aanmaken

Een praktische manier is om VLAN-interfaces in Network > Interfaces aan te maken en daarbij de bridge-interface als ouderinterface te gebruiken.

Voorbeelden:

De procedure hangt af van of de bridge zelf al een IP-adres heeft.

Als de bridge geen IP-adres nodig heeft

Als de bridge alleen transparant moet doorsturen, kan deze zonder eigen IP-adres worden beheerd. Het IP-adres voor het betreffende VLAN ligt dan op de VLAN-interface, bijvoorbeeld br0.100.

Praktische procedure:

1. Back-up maken.
2. Huidige bridge- en VLAN-configuratie documenteren.
3. Onder Network > Interfaces een nieuwe VLAN-interface toevoegen.
4. Als ouderinterface de bridge selecteren, bijvoorbeeld br0.
5. VLAN ID invoeren.
6. Zone bewust kiezen.
7. IP-adres op de VLAN-interface instellen, als de firewall in dit VLAN gateway of lokale dienst moet zijn.
8. Device Access voor de zone controleren.
9. Firewallregels en NAT-regels controleren.
10. Valideren met een testclient.

De zone is niet alleen orde in WebAdmin. Deze beslissing beïnvloedt firewallregels, Device Access, logs en veel latere probleemoplossingsstappen. Als een VLAN is bedoeld als beheer-, server- of cliëntnetwerk, moet dat in de zone zichtbaar worden.

Als de bridge momenteel het productieve IP-adres heeft

Als de bridge momenteel het IP-adres gebruikt dat in de toekomst in het VLAN bereikbaar moet zijn, moet men bijzonder voorzichtig te werk gaan. Voor de verbouwing zijn er twee nette varianten: De bridge krijgt een ander IP-adres, of de bridge blijft zonder IP-adres. Het huidige productieve adres wordt vervolgens toegewezen aan de VLAN-interface.

Dit is een wijziging met uitvalrisico. Vooraf moet worden vastgesteld:

• Via welk adres wordt WebAdmin bereikt?
• Welke cliënten gebruiken de firewall als standaardgateway?
• Welke DNS- of DHCP-instellingen wijzen naar dit adres?
• Welke Device Access-regels hangen aan de huidige zone?
• Is er een tweede beheerstoegang vanuit een niet-betrokken netwerk?

Bij externe locaties moet deze wijziging niet zonder lokaal terugweg worden gepland. Als WebAdmin en SSH precies via het betrokken bridge-IP lopen, kan een fout de administratieve toegang onderbreken.

Device Access en firewallregels daarna controleren

Na het aanmaken van de VLAN-interface is het niet voldoende om alleen het IP-adres te testen. Device Access en firewallregels moeten passen bij het nieuwe interface- en zonedesign.

Te controleren:

• Administration > Device access: Zijn Ping/Ping6, DNS, HTTPS, SSH, User Portal of VPN Portal alleen in de juiste zones toegestaan?
• Rules and policies > Firewall rules: Zijn er regels voor de nieuwe zone?
• Rules and policies > NAT rules: Wordt verkeer onverwacht vertaald?
• Network > DNS of DNS Request Routes: Bereikt de firewall de juiste DNS- of AD-servers?
• Authentication > Servers: Zijn AD, LDAP of RADIUS na de wijziging bereikbaar?

Voor lokale firewall-diensten is Device Access op Sophos Firewall veilig configureren het passende verdiepingsartikel. Voor de regelanalyse helpt Sophos Firewall Regel testen met Log Viewer en Packet Capture.

Validatie na de correctie

Een goede test moet meer dan een ping bevatten.

Test vanuit het betrokken VLAN

Vanuit een cliënt in het betrokken VLAN controleren:

1. Standaardgateway bereiken.
2. Firewall-IP op de nieuwe VLAN-interface per ping testen, indien toegestaan.
3. DNS tegen de firewall testen, als de firewall als DNS-resolver dient.
4. WebAdmin of portal alleen vanuit toegestane beheernetwerken testen.
5. Een typische applicatie of serververbinding controleren.
6. Log Viewer op passende regel-ID en zone controleren.

Test vanuit de firewall

Voor verkeer dat de firewall zelf genereert, zijn aparte tests nodig:

• AD- of LDAP-server in Authentication > Servers testen.
• DNS-resolutie via de firewall controleren.
• NTP, Syslog of monitoring-doel controleren, als deze diensten in het VLAN liggen.
• Packet Capture op de VLAN-interface gebruiken, als onduidelijk is of pakketten de firewall verlaten.

Als STAS of gebruikersgebaseerde regels zijn beïnvloed, moet daarnaast STAS op Sophos Firewall instellen worden gecontroleerd. Bij SFOS-22-upgrades hoort dit punt ook in de SFOS 22 Upgrade Check.

Veelvoorkomende fouten

Checklist

• SFOS-versie en relevantie van bekende problemen gecontroleerd.
• Bridge-interface, bridge-leden en VLAN IDs gedocumenteerd.
• Vastgesteld of oude CLI VLAN tag configuratie is gebruikt.
• Betrokken diensten naar de firewall en van de firewall geïdentificeerd.
• Back-up en alternatieve beheerstoegang aanwezig.
• VLAN-interface met bridge als ouderinterface gepland.
• Zone, Device Access, firewallregels en NAT-regels gecontroleerd.
• Tests vanuit het VLAN en vanuit de firewall uitgevoerd.
• Resultaat vastgelegd in het wijzigingslogboek of in de netwerkdocumentatie.

FAQ