Proxy ARP configureren en controleren op Sophos Firewall

Proxy ARP is op een Sophos Firewall alleen nodig wanneer een apparaat in het direct aangesloten IPv4-segment een extra doeladres via ARP opvraagt en de firewall namens dat adres met zijn MAC-adres moet antwoorden. Dit kan bijvoorbeeld voorkomen bij een extra openbaar IP-adres dat vervolgens via DNAT naar een interne server wordt doorgestuurd.

Het belangrijkste punt: Proxy ARP lost alleen de neighbour resolution op die voorafgaat aan het eigenlijke IP-datapad. Het maakt geen firewallregel, NAT-regel of retourroute aan. Daarom wordt eerst met een ARP-capture bevestigd dat precies dit antwoord ontbreekt. Pas daarna wordt één Proxy-ARP-vermelding toegevoegd en samen met de echte service getest.

⚠️ Activeer Proxy ARP niet preventief voor een volledig openbaar adresbereik. Documenteer vóór de wijziging de providertoewijzing, het interface, de oorspronkelijke ARP-status, de back-up, een onafhankelijke beheerverbinding en de rollback. Een verkeerd of dubbel gebruikt doeladres kan verkeer naar de verkeerde firewall trekken.

Proxy ARP in acht stappen

1. Verifieer bij de provider of het upstreamteam of het extra IPv4-adres via ARP op het WAN-segment wordt gezocht of als prefix naar de firewall wordt gerouteerd.
2. Sluit uit dat het adres al als alias, op een ander apparaat of in een bestaande configuratie wordt gebruikt.
3. Maak tijdens een nieuwe verbinding een ARP-capture op het verwachte inkomende interface.
4. Ga alleen verder als het ARP-verzoek voor het doeladres aankomt en aantoonbaar het vereiste antwoord van de firewall ontbreekt.
5. Voeg in de Device Console met set proxy-arp add een vermelding toe voor exact één IPv4-adres.
6. Configureer of controleer firewallregel, DNAT of route en het retourpad afzonderlijk.
7. Controleer het ARP-antwoord, de Firewall Rule ID, de NAT Rule ID en de echte service met een nieuwe verbinding.
8. Herhaal dezelfde test na een HA-failover en bij de rollback, en verwijder de vermelding gericht met set proxy-arp del.

Proxy ARP, alias en routing onderscheiden

Wat Proxy ARP werkelijk doet

Voordat een IPv4-apparaat een pakket naar een neighbour in hetzelfde Layer 2-segment kan sturen, heeft het diens MAC-adres nodig. Daarvoor verzendt het een ARP-verzoek. Met Proxy ARP beantwoordt de Sophos Firewall zo’n verzoek voor een ander doel-IP-adres met het MAC-adres van het geselecteerde interface.

Daardoor stuurt de upstream de volgende Ethernet-frames naar de firewall. Pas daarna bepalen routing, NAT en firewallregels wat er met het IP-pakket gebeurt. Een geslaagd ARP-antwoord bewijst daarom nog niet dat een gepubliceerde service werkt.

De door Sophos gedocumenteerde Device Console-opdracht geldt voor ARP en dus voor IPv4. Bij IPv6 verzorgt Neighbor Discovery de neighbour resolution. Uit deze opdracht kan geen Proxy-NDP-procedure worden afgeleid.

Welke variant bij de providertoewijzing past

• Alias-IP: Het extra adres wordt lokaal aan een fysiek firewallinterface gekoppeld. Dit past wanneer de firewall het adres zelf moet bezitten of het gericht voor NAT of systeemverkeer moet gebruiken. De volledige procedure staat in Een alias-IP instellen op Sophos Firewall.
• Proxy ARP: De firewall beantwoordt namens een doorgestuurd of vertaald IPv4-adres het ARP-verzoek. Door deze opdracht wordt het adres niet als normaal interfaceadres aangemaakt.
• Gerouteerde prefix: De upstream routeert een volledig netwerk naar het WAN-adres of naar een afgesproken next hop. Normaal vraagt de upstream dan niet elk doeladres van die prefix afzonderlijk via ARP op het WAN-segment op. Een handmatige Proxy-ARP-vermelding zou daarvoor de verkeerde oplossing zijn.
• Statische neighbour: Deze koppelt een vaste MAC-adreswaarde aan een direct bereikbare neighbour. Dat is de omgekeerde richting en geen vervanging voor Proxy ARP. De afbakening staat in De ARP- en NDP-neighbourcache controleren.

Ook een DNAT-regel betekent niet automatisch dat handmatige Proxy ARP nodig is. Test eerst het bestaande datapad. De CLI-vermelding is alleen gerechtvaardigd wanneer het providerontwerp en de capture de ontbrekende ARP-reply werkelijk aantonen.

Voorbeeld en vervangbare waarden

Het voorbeeld gebruikt een direct aangesloten openbare IPv4-toewijzing. Een HTTPS-service moet via het extra adres 203.0.113.10 bereikbaar zijn:

• WAN-interface: Port2
• WAN-adres van de firewall: 203.0.113.9/29
• provider-gateway: 203.0.113.14
• extra openbaar doel-IP-adres: 203.0.113.10
• externe testhost: 198.51.100.25
• interne server: 10.20.40.20
• service: HTTPS

203.0.113.0/24 en 198.51.100.0/24 zijn documentatienetwerken. Ze werken niet als productieadressen en moeten volledig worden vervangen door de echte providertoewijzing en een geautoriseerde externe testhost. Port2 is eveneens slechts een voorbeeld; gebruik precies het interface waarop het ARP-verzoek aantoonbaar binnenkomt.

Het /29-masker wordt niet in de Proxy-ARP-opdracht overgenomen. Het licht alleen het voorbeeldnetwerk toe. De vermelding zelf geldt bewust alleen voor 203.0.113.10. Beantwoord pas een volledig bereik wanneer eigendom, gebruik en syntaxis voor elk adres ondubbelzinnig zijn gedocumenteerd en op de gebruikte build zijn gecontroleerd.

Providerpad en ARP vóór de wijziging controleren

Vóór de CLI-ingreep worden drie mogelijke oorzaken van elkaar gescheiden:

1. Geen ARP-verzoek bereikt de firewall: Dan liggen providerpad, VLAN, switchpoort of de aanname over de toewijzing vóór de Proxy-ARP-stap.
2. Het verzoek komt aan en een apparaat antwoordt al: Dan mag geen tweede reply worden gegenereerd. Bepaal eerst de eigenaar van het zichtbare MAC-adres.
3. Het verzoek komt aan, maar niemand antwoordt: Alleen deze bevinding past bij een ontbrekende Proxy-ARP-reply op de firewall.

Open voor de opname via SSH of lokale console Option 4: Device Console. De toegang en het onderscheid tussen Device Console en Advanced Shell worden uitgelegd in Via SSH verbinding maken met Sophos Firewall.

Het volgende BPF-filter is alleen-lezen en toont uitsluitend ARP-verkeer voor het voorbeeldadres:

tcpdump 'arp and host 203.0.113.10'

Start daarna via het geautoriseerde externe testpad een nieuwe verbinding naar 203.0.113.10. Als de upstream nog een cachevermelding heeft, mag alleen die vermelding volgens de gedocumenteerde procedure van de router of provider worden vernieuwd of verlopen. Het volledig legen van alle ARP-caches of een routerherstart is voor de eerste diagnose buiten verhouding.

Interface, doel-IP en tijdstip in de capture moeten bij de test passen. Een ARP-verzoek op een ander VLAN of interface wordt niet opgelost door een vermelding op Port2.

Eén Proxy-ARP-vermelding toevoegen

Wanneer de voorcontrole ondubbelzinnig is, wordt in de Device Console exact het bevestigde adres toegevoegd:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

De vaste delen zijn set proxy-arp add interface en dest_ip. Vervang Port2 en 203.0.113.10 door het echte interface en het afzonderlijk bevestigde IPv4-adres.

Sophos documenteert ook dst_iprange, maar publiceert op de actuele Help-pagina geen volledig, getest bereikvoorbeeld. Daarom wordt hier geen indeling gegokt. Voor openbare bereiken is één adres bovendien de veiligere pilot: het beperkt de impact en maakt een eenduidige positieve en negatieve test mogelijk.

Genereer onmiddellijk na de opdracht opnieuw een vers ARP-verzoek en herhaal de capture. Het verwachte resultaat is een reply met het MAC-adres van het bedoelde firewallinterface. Als een ander MAC-adres antwoordt of meerdere antwoorden verschijnen, wordt de uitrol gestopt en eerst het adresconflict opgehelderd.

Firewallregel, NAT en retourpad afzonderlijk uitvoeren

Proxy ARP trekt het Ethernet-frame naar de firewall. Het daaropvolgende IP-datapad heeft nog steeds een eigen, inhoudelijk passende configuratie nodig.

Voor het voorbeeld met de interne HTTPS-server horen daar de volgende onderdelen bij:

• een nauw begrensde DNAT-regel van 203.0.113.10:443 naar 10.20.40.20:443;
• een passende firewallregel van de geautoriseerde WAN-bron naar de serverzone;
• logging tijdens de acceptatietest;
• een retourpad van de server via de Sophos Firewall;
• eventueel loopback, maar alleen als afzonderlijk geplande interne toepassing.

Een server publiceren met DNAT beschrijft regelpositie, Original Destination, doelzone, loopback en beveiligingsfuncties. De begrippen SNAT, DNAT, MASQ en PAT worden uitgelegd in NAT op Sophos Firewall.

Als het extra openbare adres zonder DNAT naar een downstreamsysteem moet worden gerouteerd, heeft de firewall in plaats daarvan een ondubbelzinnige route en passende regels nodig. Een overlappend netwerk mag niet worden gemaskeerd met een gegokte statische route of een Proxy-ARP-bereik. Providerprefix, interne adressering en retourpad moeten eerst als één samenhangend routingontwerp vaststaan.

ARP en de echte service testen

De acceptatietest bestaat uit een Layer 2-controle en een IP-/applicatiecontrole:

1. Genereer een vers ARP-verzoek voor 203.0.113.10.
2. Bevestig in de capture het verzoek op Port2 en exact één antwoord met het verwachte firewall-MAC-adres.
3. Open vanaf testhost 198.51.100.25 een nieuwe HTTPS-verbinding.
4. Controleer in Log viewer de verwachte Firewall Rule ID en NAT Rule ID.
5. Vergelijk in Built-in Packet Capture het binnenkomende verkeer op Port2 met het uitgaande verkeer naar de server.
6. Controleer op de server of de verbinding aankomt en het antwoord via de firewall terugloopt.
7. Test een niet-toegestane poort en een niet-geautoriseerde bron negatief.
8. Als HA wordt gebruikt, controleer dan na een gecontroleerde failover een nieuwe verbinding en een nieuwe ARP-cyclus.

Succes is pas aangetoond wanneer zowel het ARP-antwoord als de echte service kloppen. Een ping volstaat niet: ICMP kan onder Device Access of in de firewallregel bewust anders worden behandeld dan HTTPS. Filters, Status, Reason, Rule ID en de interfacevergelijking worden uitgelegd in Packet Capture op Sophos Firewall; de volledige regeltest staat in Firewallregels systematisch testen.

Problemen systematisch afbakenen

Er komt geen ARP-verzoek aan

Controleer providertoewijzing, upstreamrouting, VLAN, switchpoort en het werkelijke inkomende interface. Een lokale Proxy-ARP-vermelding kan geen verzoek beantwoorden dat het interface nooit bereikt. Bij een gerouteerde prefix is een ontbrekend ARP-verzoek voor het afzonderlijke doel-IP zelfs te verwachten; controleer dan route en next hop in plaats van Proxy ARP.

Het ARP-verzoek komt aan, maar er gaat geen antwoord uit

Vergelijk doel-IP en interface in de opdracht met de capture. Sluit daarna uit dat het interface is gewijzigd, het adres verkeerd is geschreven of de test vanuit een ander Layer 2-segment is uitgevoerd. Voeg geen breder IP-bereik toe om een onduidelijke afzonderlijke test schijnbaar te repareren.

Als de gedocumenteerde vermelding op het bevestigde interface geen antwoord blijft geven, verzamel dan firmwareversie, een korte capture en de exacte topologie voor Sophos Support. Ongedocumenteerde ingrepen in ARP- of kernelparameters via Advanced Shell zijn geen veilige standaardstap.

Er antwoorden meerdere MAC-adressen

Stop de test. Veelvoorkomende oorzaken zijn een dubbel IP-adres, een nog actief oud apparaat, een alias op een tweede firewall of een andere Proxy-ARP-vermelding. Bepaal eerst de eigenaar van elk MAC-adres en los het adresconflict op. Een firewallregel kan concurrerende ARP-antwoorden niet corrigeren.

ARP klopt, maar de service blijft onbereikbaar

Dan heeft Proxy ARP zijn taak al uitgevoerd. Controleer vervolgens Firewall Rule ID, NAT Rule ID, regelvolgorde, doelzone, service, servergateway en retourpad. Voor een nieuwe verbinding mag geen oude sessie opnieuw worden gebruikt.

Na vervanging of HA-failover is het adres kort onbereikbaar

Controleer op de node die op het moment van de gebeurtenis actief is opnieuw ARP en de echte service. De upstream kan nog een oude MAC-toewijzing bewaren. Vernieuw eerst alleen de betrokken vermelding gecontroleerd; de volledige procedure voor oude provider- of routercaches staat in ARP-problemen na een firewallmigratie oplossen.

Er wordt geen onderbrekingsvrije voortzetting van bestaande verbindingen beloofd. Doorslaggevend zijn een vers ARP-verzoek, een nieuwe applicatiesessie en de logs van de node die het verkeer daadwerkelijk verwerkt.

Rollback en beheer

Documenteer vóór het verwijderen welk gepubliceerd adres en welke service afhankelijk zijn van de vermelding. Verwijder binnen het onderhoudsvenster dezelfde afzonderlijke waarde met del:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Genereer daarna een vers ARP-verzoek. De firewall mag voor deze handmatige vermelding niet meer antwoorden, tenzij een alias, HA-peer of ander legitiem mechanisme hetzelfde adres bedient. Afhankelijke testregels en tijdelijke NAT-configuratie worden naar de gedocumenteerde oorspronkelijke toestand teruggezet.

De vermelding hoort in de beheerdocumentatie, omdat zij, anders dan een normaal interfaceadres, verklaart waarom de firewall voor het extra IP-adres antwoordt. Controleer na een interfacewijziging, vervangend apparaat, restore, firmwarewissel of HA-test opnieuw doeladres, interface, ARP-reply en echte service.

Checklist

• Providertoewijzing en ARP- in plaats van routingmodel bevestigd.
• Aangetoond dat het doel-IP-adres bij de eigen omgeving hoort en niet dubbel is toegewezen.
• ARP-verzoek komt op het gedocumenteerde interface aan.
• Ontbrekend antwoord vóór de wijziging met een capture aangetoond.
• Slechts één pilotadres met dest_ip ingevoerd.
• Firewallregel, NAT of route en retourpad afzonderlijk gecontroleerd.
• Verwacht MAC-adres, Firewall Rule ID en NAT Rule ID bevestigd.
• Niet-toegestane bron en niet-toegestane poort negatief getest.
• HA-failover of vervangend pad met een nieuwe verbinding gecontroleerd.
• Exacte del-opdracht en oorspronkelijke toestand gedocumenteerd.

FAQ