Sophos Firewall Controleer bridge-VLAN's voor SFOS 22

Bridge-interfaces op Sophos Firewall zijn praktisch als een bestaand Layer 2-netwerk transparant moet worden voortgezet of een migratie moet worden geïmplementeerd zonder onmiddellijke IP wijzigingen. Met VLAN’s op een bridge wordt het ontwerp echter al snel foutgevoelig: er is dan sprake van forwarding tussen netwerken, verkeer naar de firewall zelf, Device Access, DNS, AD, authenticatie en vaak oude CLI-configuraties.

Precies op dit punt is er een belangrijk probleem met SFOS 22. Sophos vermeldt een probleem in de huidige lijst met bekende problemen waarbij bruginterfaces met CLI VLAN tagconfiguraties in SFOS 22.0 GA en SFOS 22.0 MR1 VLAN-getagd verkeer niet correct verwerken als dit verkeer afkomstig is van de Sophos Firewall zelf of eindigt op de firewall. Dit kan bijvoorbeeld invloed hebben op Active Directory, DNS, Device Access, STAS, LDAP, RADIUS of beheertoegang, ook al wordt normaal verkeer via de bridge gerouteerd.

Sophos beschrijft legacy CLI VLAN tagging inmiddels ook als deprecated. Zulke verouderde configuraties kunnen upgrades naar SFOS 22.0 MR2 en latere versies verhinderen. Deze controle is daarom niet alleen troubleshooting na een upgrade, maar ook een nuttige voorbereiding voor het volgende onderhoudsvenster.

Dit artikel is geen algemeen VLAN basishoofdstuk. Voor het plannen van zones, interfaces, VLAN’s, bruggen en LAG’s past Sophos Firewall Zones en interfaces configureren als eerste. Dit gaat specifiek over de brug VLAN speciaal geval na SFOS 22.

Wanneer dit onderwerp relevant is

De controle is zinvol als verschillende punten samenkomen:

• De firewall draait op SFOS 22.0 GA of SFOS 22.0 MR1.
• Er is een bridge-interface, bijvoorbeeld br0.
• VLAN’s werden historisch gebouwd met behulp van CLI VLAN tagconfiguratie zoals system vlan-tag of werden overgenomen van een oude configuratie.
• Firewallservices zelf moeten een getagde VLAN bereiken.
• Na een upgrade werken AD, DNS, authenticatie, monitoring of beheertoegang slechts gedeeltelijk.
• Het normale clientverkeer via de brug lijkt nog steeds actief te zijn.
• Een upgrade naar SFOS 22.0 MR2 of later is gepland of wordt geblokkeerd door legacy CLI VLAN tagging.

Het laatste punt is belangrijk: als de brug verkeer tussen netwerken blijft doorsturen, zal het probleem in eerste instantie niet lijken op een brugstoring. In de praktijk kijk je vaak op de verkeerde plek, zoals bij firewallregels, DNS, STAS of de domeincontroller.

Begrijp de getroffen verkeersrichting

Je moet drie soorten verkeer duidelijk scheiden.

De soorten verkeer verschillen aanzienlijk:

• Verkeer dat door de bridge gaat: Een client in VLAN 100 praat met een server in VLAN 100. Dit werkt mogelijk nog steeds, maar bewijst niet dat het verkeer naar de firewall werkt.
• Verkeer naar firewall: Een client gebruikt de firewall als DNS-server of WebAdmin-bestemming. Juist dit verkeer kan hinder ondervinden omdat het bij de firewall eindigt.
• Verkeer van de firewall: De firewall vraagt ​​AD, DNS, LDAP, RADIUS, NTP of Syslog bestemmingen op. Dit is ook van cruciaal belang omdat de firewall zelf de afzender is.

Als er slechts één applicatie tussen twee hosts wordt getest, kan de fout niet met zekerheid worden geïdentificeerd. De test moet opzettelijk een service bevatten die eindigt op de Sophos Firewall of wordt gemaakt door de firewall.

Typische symptomen

Mogelijke tekenen zijn:

• Op gebruikers gebaseerde regels werken niet langer betrouwbaar omdat AD, STAS of LDAP niet op een stabiele manier kunnen worden bereikt.
• DNS-query’s naar de firewall mislukken vanaf individuele VLAN’s.
• Ping of HTTPS op lokale firewallservices werkt niet vanaf een VLAN, ook al zien de firewallregels er plausibel uit.
• Monitoring of Syslog lijkt onvolledig als de firewall een doel moet bereiken in een getagde VLAN.
• Packet Capture laat zien dat verkeer tussen eindsystemen zichtbaar is, maar firewallservices zelf reageren niet zoals verwacht.
• Na een SFOS-22 upgrade treden de symptomen op zonder dat er bewust iets aan de switch- of firewallregels is gewijzigd.

Dergelijke symptomen mogen niet onmiddellijk worden aangepakt met brede toestemmingsregels of goedkeuringen voor apparaattoegang. Ten eerste moet duidelijk zijn of het interfaceontwerp zelf wordt beïnvloed.

Snelle afbakening vóór conversie

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

Praktische classificatie:

• Slechts één applicatie tussen twee hosts werkt niet: Waarschijnlijker zijn firewallregel, NAT, doelsysteem of retourpad. Eerst test de firewallregel en voor wegvallen analyseer weggevallen pakketten.
• WebAdmin, DNS of ping naar de firewall vanaf een VLAN werkt niet: Controleer Device Access, zone, lokale service of bridge VLAN speciaal geval. Test vervolgens het verkeer naar de firewall afzonderlijk.
• Firewall bereikt AD, LDAP, RADIUS, DNS of Syslog niet in VLAN: Controleer verkeer van de firewall, routing, DNS of bridge VLAN speciaal geval. Gebruik tests rechtstreeks vanuit de firewallconfiguratie en de juiste servicelogboeken.
• Er is normaal clientverkeer actief, maar de services van de firewall zelf niet: Een speciaal geval van Bridge VLAN wordt waarschijnlijker. Controleer het bridge-ontwerp, de oude CLI VLAN-tagconfiguratie en VLAN-interface voor bridge.
• Er zijn helemaal geen overeenkomende loggegevens: Controleer loggen, filteren, lokale service of niet-gelogde bridge/NAT speciaal geval. Combineer Log Viewer, Packet Capture en relevante Sophos Firewall servicelogboeken.

Voor DNS-problemen is het ook van belang of clients de firewall als oplosser gebruiken of dat de firewall zelf DNS-verzoekroutes naar interne servers gebruikt. Het tweede geval betreft verkeer van de firewall en kan bij problemen met Bridge VLAN er anders uitzien dan normaal clientverkeer. De basisbeginselen vindt u in DNS-verzoekroutes instellen op Sophos Firewall.

Als de snelle afbakening duidelijk verwijst naar lokale firewalldiensten of verkeer gegenereerd door de firewall, moet de conversie toch worden gepland. Een brugcorrectie zonder back-up, onderhoudsvenster en alternatief toegangspad is te riskant voor productieve netwerken.

Bestaand ontwerp opnemen

Voordat u wijzigingen aanbrengt, moet u de huidige status documenteren. Bijzonder belangrijk zijn:

• Naam van de bridge-interface, bijvoorbeeld br0.
• Bridge-leden, d.w.z. deelnemende fysieke interfaces, VLAN’s, RED interfaces of LAG’s.
• IP adres van de bridge, indien beschikbaar.
• VLAN ID’s die over de brug gaan.
• Poortprofiel wisselen: Tagged VLAN’s, Native VLAN, Trunk of toegangspoort.
• Services die eindigen op de firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Services die de firewall moet bereiken: AD, LDAP, RADIUS, DNS, NTP, Syslog, Centraal, Monitoring.

Als de structuur uit een oude migratie komt, moet u ook controleren of VLAN’s via CLI-configuratie zijn ingesteld. Juist deze erfenis wordt vaak niet meer in gedachten gehouden als de firewall in de loop der jaren alleen maar is bijgewerkt.

⚠️ Tijdens de dagelijkse werkzaamheden moet je niet spontaan experimenteren met bridge-interfaces en VLAN’s. Een onjuiste wijziging kan van invloed zijn op de beheertoegang, DNS, authenticatie of volledige clientnetwerken. Vóór de correctie zijn een back-up, een onderhoudsvenster en een alternatief toegangspad vereist.

Bridge-specifieke valkuilen vóór de correctie

Sophos beschrijft drie bridge-beperkingen die vóór de wijziging bewust moeten worden gecontroleerd.

Ten eerste: een bridge zonder IP-adres kan verkeer laten vallen als het verkeer overeenkomt met een firewallregel met web proxy filtering of met een NAT-regel. Volgens Sophos worden deze drops niet gelogd. Als een NAT-regel toch nodig is, moet die zo worden afgebakend dat source translation voor de bridge zonder IP-adres op Original blijft. Anders zoekt men in Log Viewer naar een drop die daar nooit verschijnt.

Ten tweede: VLAN filtering op de bridge geldt alleen voor gebridged verkeer, niet voor gerouted verkeer. Als Filter VLANs is ingeschakeld, maar er geen toegestane VLAN IDs zijn ingevoerd, wordt tagged verkeer van alle VLANs gedropt; untagged verkeer blijft uitgezonderd. Tijdens tests kan dit lijken op een inconsistent VLAN-probleem.

Ten derde: bridge-interfaces zijn geen vervanging voor elk ontwerp. Sophos noemt beperkingen voor Dynamic DNS, DHCP client, PPPoE en IPsec VPN. Als een van deze functies deel uitmaakt van het doelontwerp, moet de bridge-workaround niet geïsoleerd worden toegepast; het interfaceontwerp moet opnieuw worden beoordeeld.

Tijdelijke oplossing en upgradevoorbereiding

Een praktische manier is om VLAN interfaces te maken in Network > Interfaces, waarbij u de bridge-interface als bovenliggende interface gebruikt.

Nieuwe of opgeschoonde ontwerpen mogen niet meer op system vlan-tag steunen. Als zulke CLI-tags nog bestaan, moeten ze worden gedocumenteerd, naar VLAN-interfaces in WebAdmin worden gemigreerd en pas daarna mag de firmware-upgrade worden voortgezet. Dit vermindert zowel het SFOS 22 bridge-speciale geval als latere upgradeblokkades.

Voorbeelden:

• VLAN 100: br0.100
• VLAN 200: br0.200

Bij het aanmaken in WebAdmin zijn drie velden doorslaggevend: Interface moet de bridge zijn, Zone moet passen bij het beveiligingsdoel van de VLAN en VLAN ID moet uniek zijn. Sophos staat WebAdmin VLAN IDs van 1 tot 4094 toe; dezelfde VLAN ID mag niet meerdere keren op dezelfde parent interface worden gepland.

Het proces is afhankelijk van het feit of de bridge zelf al een IP-adres heeft.

Als de bridge geen IP adres nodig heeft

Als de brug alleen transparant moet doorsturen, kan deze zonder eigen IP-adres worden gebruikt. Het IP-adres voor de betreffende VLAN bevindt zich dan op de VLAN-interface, bijvoorbeeld br0.100.

Praktisch proces:

1. Maak een back-up.
2. Documenteer de huidige brug en VLAN-configuratie.
3. Voeg een nieuwe VLAN interface toe onder Network > Interfaces.
4. Selecteer de bridge als bovenliggende interface, bijvoorbeeld br0.
5. Voer VLAN ID in.
6. Kies bewust je zone.
7. Stel het IP adres in op de VLAN interface als de firewall zich in deze VLAN Gateway of lokale service moet bevinden.
8. Controleer Device Access voor de zone.
9. Controleer de firewallregels en NAT-regels.
10. Valideer met een testclient.

De zone is niet alleen maar een orde in de WebAdmin. Deze beslissing is van invloed op de firewallregels, Device Access, logboeken en veel latere stappen voor probleemoplossing. Indien een VLAN bedoeld is als beheer-, server- of clientnetwerk, dient dit zichtbaar te zijn in de zone.

Als de bridge voorheen het productieve IP adres had

Als de bridge momenteel het adres IP gebruikt, dat in de toekomst toegankelijk moet zijn in VLAN, moet u bijzonder voorzichtig zijn. Er zijn twee schone varianten voor de conversie: De bridge krijgt een ander IP adres, of de bridge blijft zonder IP adres. Het vorige productieve adres wordt vervolgens toegewezen aan de VLAN-interface.

Dit is een verandering met risico op mislukking. Het moet vooraf worden verduidelijkt:

• Welk adres wordt gebruikt om WebAdmin te bereiken?
• Welke clients gebruiken de firewall standaard Gateway?
• Welke DNS- of DHCP-instellingen verwijzen naar dit adres?
• Welke toegangsregels voor apparaten zijn van toepassing op de vorige zone?
• Is er een tweede beheertoegang vanaf een niet-getroffen netwerk?

Voor afgelegen locaties mag deze wijziging niet worden gepland zonder een lokaal retourpad. Als WebAdmin en SSH precies over de betrokken bridge IP lopen, kan een fout de beheerderstoegang onderbreken.

Device Access en controleer daarna de firewallregels

Nadat u de VLAN-interface hebt gemaakt, is het niet voldoende om alleen het IP-adres te testen. Device Access en firewallregels moeten overeenkomen met het nieuwe interface- en zoneontwerp.

Om te controleren:

• Administration > Device access: Zijn Ping/Ping6, DNS, HTTPS, SSH, User Portal of VPN portal alleen toegestaan in de juiste zones?
• 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-aanvraagroutes: bereikt de firewall de juiste DNS- of AD-servers?
• Authentication > Servers: Zijn AD, LDAP of RADIUS toegankelijk na de wijziging? Voor lokale firewallservices is Device Access veilig configureren Sophos Firewall het juiste diepgaande artikel. Sophos Firewall Testregel met Log Viewer en Packet Capture helpt bij regelanalyse.

Validatie na correctie

Een schone test moet meer dan één ping bevatten.

Test van de getroffen VLAN

Controle van een client in de getroffen VLAN:

1. Bereik standaard Gateway.
2. Test de firewall IP op de nieuwe VLAN interface via ping, indien toegestaan.
3. Test DNS tegen de firewall als de firewall als DNS-resolver fungeert.
4. Test WebAdmin of portal alleen vanuit toegestane beheernetwerken.
5. Controleer een typische applicatie- of serververbinding.
6. Controleer Log Viewer voor overeenkomende regel-ID en zone.

Test vanuit de firewall

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

• Test AD- of LDAP-servers in Authentication > Servers.
• Controleer de DNS-resolutie via de firewall.
• Controleer NTP, Syslog of monitoringdoel als deze services zich in VLAN bevinden.
• Gebruik Packet Capture op de VLAN interface als het onduidelijk is of pakketten de firewall verlaten.

Als STAS of gebruikersgebaseerde regels worden beïnvloed, moet ook Set up STAS on Sophos Firewall worden aangevinkt. Voor SFOS-22 upgrades hoort dit punt ook thuis in de SFOS 22 Upgrade Check.

Veelvoorkomende fouten

Typische valkuilen:

• Test alleen client-naar-server-verkeer: De bridge lijkt in orde, hoewel lokale firewallservices worden beïnvloed. Test ook het verkeer van en naar de firewall.
• Verplaats bridge IP zonder abonnement: WebAdmin, DNS of Gateway kunnen mislukken. Back-up, onderhoudsvensters en alternatieve toegang voorbereiden.
• Selecteer de zone verkeerd voor de nieuwe VLAN interface: Regels, Device Access en logs passen niet. Kies een zone op basis van veiligheidsdoeleinden, niet op basis van gewoonte.
• Device Access te wijd open: Het probleem lijkt opgelost, maar de beheerservices zijn onnodig toegankelijk. Local Service ACL specifiek abonnement.
• Controleer de switchpoort niet: VLAN arriveert onjuist of is niet gecodeerd. Valideer Tagged/Untagged, Native VLAN en Trunk profiel.
• Negeer oude CLI-configuratie: Fout blijft onverklaard na upgrade. Documenteer het oude ontwerp en migreer naar WebAdmin-VLAN interfaces.

Controlelijst

• SFOS versie en relevantie van bekend probleem gecontroleerd.
• Bridge-interface, bridge-leden en VLAN ID’s gedocumenteerd.
• Verduidelijkt of de oude CLI VLAN-tagconfiguratie werd gebruikt.
• Bridge-specifieke NAT/web proxy drops en VLAN filtering gecontroleerd.
• Geplande upgrade naar SFOS 22.0 MR2 of later gecontroleerd op legacy CLI VLAN tags.
• Getroffen services van en naar de firewall geïdentificeerd.
• Back-up en alternatieve beheertoegang beschikbaar.
• VLAN interface gepland met bridge als bovenliggende interface.
• Zone, Device Access, firewallregels en NAT regels aangevinkt.
• Tests uitgevoerd vanaf de VLAN en vanaf de firewall.
• Resultaat vastgelegd in het wijzigingslogboek of in de netwerkdocumentatie.

Veelgestelde vragen