Verouderde bridge-VLAN-tagging vóór SFOS 22 MR2 vervangen

Bridge-interfaces op Sophos Firewall zijn nuttig om een bestaand Layer 2-netwerk transparant te houden of een migratie uit te voeren zonder de IP-adressen direct te wijzigen. Zijn VLAN-tags eerder met system vlan-tag op een bridge ingesteld, vervang die configuratie dan vóór een upgrade naar SFOS 22.0 MR2 of later door VLAN-interfaces in WebAdmin. Dit is geen cosmetische wijziging: in GA en MR1 kan verkeer van of naar de firewall uitvallen en vanaf MR2 blokkeert de verouderde configuratie de upgrade.

Probleem NC-181672 treft bridge-interfaces met CLI-VLAN-tagconfiguraties in SFOS 22.0 GA en MR1: VLAN-getagd verkeer dat afkomstig is van de Sophos Firewall of op de firewall eindigt, wordt niet correct verwerkt. Dit kan bijvoorbeeld Active Directory, DNS, Device Access, STAS, LDAP, RADIUS of beheertoegang beïnvloeden, terwijl de bridge normaal verkeer wel blijft doorsturen.

Verouderde CLI-VLAN-tagging is achterhaald: de configuratie blokkeert een upgrade naar SFOS 22.0 MR2 of later en een back-up die haar bevat kan niet op SFOS 22.0 GA of later worden teruggezet. Voer deze controle daarom uit vóór de upgrade en vóór het maken van de daarvoor bestemde back-up. De SFOS 22-upgradecontrole documenteert de gecontroleerde doelrelease MR2 Build 546, het upgradepad en andere versiespecifieke blokkades. Is een andere doelbuild gepland, laat deze interne upgradecontrole dan vóór de wijziging actualiseren; neem de MR2-gegevens niet ongecontroleerd over.

Dit artikel is geen algemeen hoofdstuk over VLAN’s. Begin voor het plannen van zones, interfaces, VLAN’s, Bridges en LAG’s met Zones en interfaces op Sophos Firewall configureren. De normale configuratie, beveiliging en controle staan in Een Bridge-interface op Sophos Firewall configureren. Hier gaat het specifiek om het bijzondere geval van VLAN’s op Bridges 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

Vóór de wijziging moeten drie bridge-beperkingen zorgvuldig 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. Deze drops worden 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. Er gelden 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.

Ondersteunde VLAN-interfaces maken

De ondersteunde workaround is VLAN-interfaces onder Network > Interfaces te maken met de bridge als parent. Fysieke, RED-, bridge- en LAG-interfaces zijn geldige parents.

Vóór SFOS 18.0 was system vlan-tag nodig voor VLAN-tagged communicatie over bridges. Sinds SFOS 18.0 is VLAN-over-bridge beschikbaar in WebAdmin. Voor de volgende CLI-opdracht is geen Device Console, Advanced Shell, menunummer, prompt of privilegeniveau gespecificeerd. Gebruik uitsluitend de ondersteunde CLI-context van de firewall waarin de opdracht beschikbaar is. Is dat niet zo, stop dan en vraag Sophos Support in plaats van shell of context te raden. Controleer de legacy-configuratie eerst met deze alleen-lezen opdracht:

system vlan-tag show

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. WebAdmin accepteert VLAN IDs van 1 tot 4094; 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. Exporteer een back-up als documentatie, maar reken er niet op dat deze op SFOS 22 als terugval kan worden hersteld.
2. Documenteer de huidige brug en VLAN-configuratie.
3. Kies onder Network > Interfaces voor Add interface > Add VLAN.
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 de wijziging met een testclient en maak pas na geslaagde tests een nieuwe back-up.

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.

Legacy-configuratie verwijderen en de upgrade voorbereiden

Maak eerst alle benodigde VLAN-interfaces onder Network > Interfaces met de bridge als parent, verplaats zo nodig het bridge-IP naar de juiste VLAN-interface en valideer data- en beheerpaden. Controleer bij HA via de ondersteunde statusinterface of peer en synchronisatie gezond zijn en maak een back-up van elk knooppunt waar platform en supportprocedure dat vereisen. Stop vóór reset of upgrade en escaleer als de status ongezond of onduidelijk is; verzin geen HA- of synchronisatieopdracht. Verwijder de legacy-instelling pas met gedocumenteerde mapping, actieve alternatieve toegang en vervulde HA-voorwaarden, in dezelfde ondersteunde CLI-context als hierboven:

system vlan-tag reset

Voer system vlan-tag show opnieuw uit. Blijft configuratie staan, mislukt de reset of is de uitvoer onduidelijk, stop dan: start geen upgrade en keur de nieuwe back-up niet als opgeschoond herstelpunt goed. Bewaar uitvoer, precheck en configuratie en escaleer naar Sophos Support zonder ongedocumenteerde opdrachten. Er is geen gedocumenteerde omkering op opdrachtniveau voor system vlan-tag reset: geslaagde controles bevestigen de opschoning, niet de terugval. Maak de legacy-instelling na reset niet opnieuw met een gegokte opdracht. Moet de wijziging terug, stop en escaleer voor een door de leverancier goedgekeurd herstel op de oorspronkelijke ondersteunde firmware. Maak na geslaagde tests een nieuwe back-up, herhaal de precheck en upgrade pas daarna. Maak een herstelbare back-up via dezelfde opschoning op de bronfirewall, maak zo nodig de VLAN-interface, valideer en maak dan de back-up. Dit repareert geen oude back-up met system vlan-tag.

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.
• Controleer onder Diagnostics > Packet capture de VLAN-interface. Generated markeert pakketten die de firewall maakt en Consumed pakketten die voor de firewall bestemd zijn; vergelijk ook In interface, Out interface, Rule ID, Status en Reason.

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.

Terugval en afronding

Noteer vóór de wijziging het IP-adres en de zone van de bridge, de VLAN-ID’s, het switchpoortprofiel en afhankelijke regels en services. Bereid alternatieve of lokale beheertoegang en een door de leverancier goedgekeurd herstelplan voor. Vóór system vlan-tag reset kunnen geplande WebAdmin-wijzigingen in gedocumenteerde volgorde worden teruggedraaid: verwijder een verplaatst IP eerst van de VLAN-interface en wijs het daarna weer aan de bridge toe; herstel zone, regels, Device Access en switchpoortprofiel en controleer de verbinding. Dit keert reset niet om. Na reset is geen omkering op opdrachtniveau gedocumenteerd: stop bij mislukte acceptatie en escaleer voor goedgekeurd herstel op de oorspronkelijke ondersteunde firmware. Reset of upgrade bij HA geen knooppunt wanneer peer of synchronisatie ongezond of onduidelijk is en bewaar de toepasselijke back-up van elk knooppunt.

Maak na een geslaagde controle een nieuwe back-up. De oude back-up met legacy CLI VLAN tagging is geen terugvaloptie voor SFOS 22.0 GA of later. Meldt de precheck de configuratie nog steeds, bewaar dan configuratie en melding en neem contact op met Sophos Support in plaats van ongedocumenteerde CLI-wijzigingen te proberen.

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 van elk toepasselijk knooppunt en alternatieve beheertoegang beschikbaar; HA-peer en synchronisatie gezond.
• 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.
• Herstelgrens vastgelegd: geen gedocumenteerde omkering voor system vlan-tag reset; na de correctie een nieuwe back-up gemaakt.
• Resultaat vastgelegd in het wijzigingslogboek of in de netwerkdocumentatie.

Veelgestelde vragen