Switch reageert niet op CARP gedeeld IP adres van FW/GW

[Glashelder]

Wij hebben hier een tweetal servers met PfSense die verkeer tussen verschillende VLAN's in ons bedrijfsnetwerk routeren (en filteren uiteraard, maar dat maakt even niet uit).

Deze twee servers delen op elk VLAN een IP adres om de beschikbaarheid te kunnen garanderen. Hiervoor wordt CARP gebruikt en hier heb ik eigenlijk nog nooit echt een probleem mee gehad, tot nu toe. Het gedeelde IP op elk vlan is altijd .254, het IP van de eerste firewall .253, en van de tweede .252.

We hebben hier switches van diverse merken, waaronder 6 switches van D-Link. 4 hiervan werken zonder problemen, maar 2 van deze switches weigeren te reageren op het door de firewall gedeelte IP adres, dat zich op het management VLAN van deze switches bevindt.

Nu begin ik zo langzamerhand te vermoeden dat er zich een of andere bug in de firmware van deze switches moet bevinden (allebei zijn ze up-to-date). De ene is een DGS-1210-10P en de andere een DGS-1210-28. Een andere DGS-1210-24 die ertussenin zit doet het echter prima Deze is echter 'hardware revision' D1 waar de probleemgevallen C1 zijn. Sterker nog, na het typen van het hele verhaal ben ik het nog eens nagegaan, maar alle werkende switches zijn van de revisie D1.

---

Probleem:
- Als de switch als gateway 192.168.212.254 heeft (het gedeelde IP adres), dan reageert de switch niet op pings uit andere vlans (en dus ook niet op ander verkeer).
- Verander ik dit gateway adres naar .253, dan werkt het wel.

---

Debuggen:
- Een virtuele machine in het management vlan kan probleemloos de switch pingen vanaf de andere kant van ons terrein (er loopt nogal wat glasvezel over ons bedrijfsterrein). Het gaat dus niet ergens mis op weg naar deze switch (er zitten diverse switches tussen).
- Een laptop die aan een van de niet reagerende switches in het management subnet hangt, reageert netjes op pings uit andere vlans. (dit sluit ook uit dat het aan de firewall rules ligt, IMO).
- Pingen vanaf de switch (telnet) naar het shared IP geeft geen kik.
- Pingen vanaf de firewall naar de switch geeft wel een response, maar de ping komt vanaf het niet gedeelte IP adres, dus dat is opzich logisch. Verzend ik de ping vanaf het gedeelte IP, dan werkt het niet:

code:

[2.1.5-RELEASE][root@pfsense01.<>.nl]/root(21): ping -S 192.168.212.254 192.168.212.110
PING 192.168.212.110 (192.168.212.110) from 192.168.212.254: 56 data bytes
^C
--- 192.168.212.110 ping statistics ---
27 packets transmitted, 0 packets received, 100.0% packet loss
[2.1.5-RELEASE][root@pfsense01.<>.nl]/root(22): ping -S 192.168.212.253 192.168.212.110
PING 192.168.212.110 (192.168.212.110) from 192.168.212.253: 56 data bytes
64 bytes from 192.168.212.110: icmp_seq=0 ttl=64 time=7.379 ms
64 bytes from 192.168.212.110: icmp_seq=1 ttl=64 time=8.451 ms
64 bytes from 192.168.212.110: icmp_seq=2 ttl=64 time=9.388 ms
^C
--- 192.168.212.110 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.379/8.406/9.388/0.821 ms

(de niet werkende switch hier zit op 192.168.212.110).

- De niet werkende switches kennen het MAC adres van het gedeelte IP, dus het gaat ook niet mis op ARP niveau.
- Idem voor de firewall. Ook die kent het MAC adres van de switch.
- Een packet capture aan de kant van de firewall leert dat de switch niet meer reageert op pings zodra de gateway van .253 naar .254 gaat.
- Het ligt ook niet aan het MAC adres van het gedeelte IP (CARP IP's krijgen een MAC adres uit een specifieke reeks). Hang ik een ander MAC adres uit deze reeks (klik) aan een virtuele machine dan kan ik deze gewoon pingen vanaf de switch. Er zit dus geen filter in de switch die "ongeldige mac" adressen filtert oid.

Mijn conclusie is dat er een bug zit in de firmware, of in de hardware. De firmware geïnstalleerd op de C1 versie is 4.00.012 (dit is de meest recente versie) en op de D1 4.10.023. Ik vindt het wel heel toevallig dat ik "toevallig" problemen ondervind met twee switches die allebei revisie C1 zijn. Een van de switches die niet goed werkt blijkt een 'B1' revisie te hebben.

Heeft er iemand nog andere ideeën?

[Bjornski]

Als je op de firewall de ARP tabel uitleest, zie je dan het mac adres van de switch, gekoppeld aan het juiste IP?
Andersom, als je de ARP tabel van de switch uitleest, zie je dan het (virtuele) mac-adres van de firewalls met daaraan het gekoppelde IP?

CARP stuurt gratuitous arps (kortom, de firewall stuurt zelf een broadcast ARP pakketje het netwerk op en herhaalt dat periodiek). Als de switch geen GRARPS snapt, dan kun/moet je proxy-arp inschakelen op de firewall. Dan werkt het naar alle waarschijnlijkheid wel.

offtopic:
D-link:

[ Voor 3% gewijzigd door Bjornski op 07-11-2014 12:59 ]

[Glashelder]

Ja het klopt allemaal helaas

De switch ziet 00-00-5E-00-01-07 op poort 9, op VLAN 100, wat correct is. Op het moment van schrijven was het MAC adres van de switch even verdwenen uit de firewall, maar na een ping (waar geen response op kwam ) staat deze weer netjes in de tabel:

code:

[2.1.5-RELEASE][root@pfsense01.<>.nl]/root(23): arp -a | grep 212.110
? (192.168.212.110) at c8:d3:a3:9e:a0:14 on bge1_vlan100 expires in 1102 seconds [vlan]

Bjornski schreef op vrijdag 07 november 2014 @ 12:59:

offtopic:
D-link:

offtopic:
Ach ja je moet wat zonder budget.. afgezien van dit probleem werken ze voortreffelijk

[Bjornski]

En andersom dan? Wat zegt de ARP-Tabel van de switch?

Als die switch een ICMP ping pakketje ontvangt van een host op hetzelfde VLAN, is dat volgens mij niet accuut equivalent aan een entry in de ARP tabel (maar ik kan het mis hebben).

Ook vond ik met een beetje googelen nog dit (ik vond het interessant, omdat wij in één situatie ook PFSense gebruiken):
https://forum.pfsense.org/index.php?topic=66838.0

Als laatste, heb je Proxy-arp ingeschakeld op PFSense? Maakt dat nog wat uit?

[Glashelder]

Ze zien elkaar gewoon zoals ze elkaar horen te zien.

De switch ziet het juiste MAC adres op het juiste vlan en de firewall ook.

Switch:


00-05-5E-00-01-07 = gedeeld IP van de firewall.

Firewall:

Als die switch een ICMP ping pakketje ontvangt van een host op hetzelfde VLAN, is dat volgens mij niet accuut equivalent aan een entry in de ARP tabel (maar ik kan het mis hebben).

Nouja, dat lijkt mij toch wel? Als een switch uberhaupt een pakketje van een (tot dan toe) onbekend MAC adres tegenkomt dan zal hij dit toevoegen aan zijn MAC/ARP tabel? Maar anyway, ongeacht ons meningsverschil hier, hij voegt dus wel netjes de MAC adressen toe aan de tabel.

Als laatste, heb je Proxy-arp ingeschakeld op PFSense? Maakt dat nog wat uit?

Proxy ARP is voor zover ik weet toch gewoon een alternatief voor CARP? Het is in ieder geval niet iets wat ik zonder meer wil (en durf) te veranderen tijdens werktijd.

Bedankt voor uw input zo ver

[Bjornski]

Dat plaatje wat je laat zien is van de MAC tabel. Dat geeft dus aan dat de switch het juiste MAC heeft geleerd in het juiste VLAN. Maar, dat zegt nog niet zoveel over ARP (welk IP er bij dat MAC hoort).

Kun je in die switch niet de ARP tabel uitlezen?

En een andere vraag; als je een copy-port (port mirroring, sniffen, you name it) maakt op de poort waar de actieve firewall aan hangt, en je snift dan met Wireshark het verkeer, zie je dan je ping voorbij komen (of misschien alleen ARP requests)?

Proxy-arp zorgt er alleen voor dat de firewall gaat reageren op ARP requests waar de firewall anders niet direct op zou reageren. Het is dus niet een vervanger van CARP.

Als CARP niet, of niet goed reageert op ARP requests, dan kun je met proxy arp alsnog forceren dat er op ARPs wordt gereageerd.
Je hebt helemaal gelijk; moet je niet tijdens werktijd mee gaan hobbyen, maar kan een oplossing bieden.

offtopic:
... mompelt iets over Juniper SRX firewalls, die als je meerdere routing-instances gebruikt alleen reageren op arp requests van destination NAT ips, als je ook proxy-arp instelt. Ander scenario, zelfde workaround ...

Aanvulling:

Nouja, dat lijkt mij toch wel? Als een switch uberhaupt een pakketje van een (tot dan toe) onbekend MAC adres tegenkomt dan zal hij dit toevoegen aan zijn MAC/ARP tabel?

MAC tabel: zeker weten. ARP tabel weet ik niet 100% zeker. Kan zijn dat die switch (of wat voor host dan ook) alsnog eerst een ARP wil zien, of wellicht ARP entries cached. Als je tegen de eerdere gerefereerde bug aanloopt, zou dat in theorie het scenario kunnen zijn.

[ Voor 17% gewijzigd door Bjornski op 07-11-2014 14:04 ]

[Glashelder]

Dat plaatje wat je laat zien is van de MAC tabel. Dat geeft dus aan dat de switch het juiste MAC heeft geleerd in het juiste VLAN. Maar, dat zegt nog niet zoveel over ARP (welk IP er bij dat MAC hoort).

Ja verdomd je hebt natuurlijk helemaal gelijk Helemaal niet bij nagedacht toen ik dat schreef..

Je kan alleen de 'Dynamic Forwarding Table' zien. Dat zal inderdaad alleen de MAC table zijn die voor switching gebruikt wordt.

Overigens heb ik ook een support request ingediend bij D-Link. Ben benieuwd of daar uberhaupt op gereageerd wordt

Ik zal maandag eens even gaan sniffen. Maandag zal ik het hier posten

[Glashelder]

Vandaag ben ik even gaan sniffen met de volgende resultaten:

- Er worden door de switch ARP verzoeken verstuurd.
- Deze worden netjes beantwoord door de firewall.
- Het antwoord op het ARP pakket wordt niet door de switch in de ARP tabel opgeslagen.
- Het is wel zeker dat het antwoord bij de switch aan komt (laptop aan de switch, uplink gemirrord naar mijn laptop, en dan kan ik netjes zien dat het antwoord bij de switch aan komt).

Kan het zijn dat de switch het antwoord van de firewall niet accepteert omdat het source adres afwijkend is? (omdat het een virtueel adres is).

Nog niks gehoord van D-Link

[johnkeates]

Waarschijnlijk ondersteunt je switch CARP gewoon niet, kijk even welke standaarden ie wel ondersteunt en gebruik dat.

Kans is ook dat een niet-ondersteunde technologie die wel zou kunnen werken gewoon niet werkt om dat beveiliging van een switch dan bijvoorbeeld MAC spoofing or ARP Poisoning tegen probeert te gaan.

[Glashelder]

Nou ja, deze switch hoeft geen CARP te ondersteunen. Ik ken eigenlijk geen enkele switch die expliciet CARP ondersteund (is volgens mij nergens voor nodig). Als die gewoon netjes luistert naar de ARP reply dan is er niets aan de hand. En voor zover ik weet is CARP ook geen officieel erkend protocol.

Dat tweede vermoed ik verder ook, maar alles op dat gebied staat uitgeschakeld.

[ Voor 9% gewijzigd door Glashelder op 10-11-2014 15:04 ]

[Bjornski]

Zou je eens een screenshot van je wireshark-capture kunnen maken?
Hoe kom je tot de conclusie dat de switch de ARP reply niet in zijn tabel opneemt? Kun je nu wel een ARP tabel uitlezen dan?

Het kan zijn dat er een bug zit in de protocol-implementatie van de D-Link switch. Vanuit de D-Link switch geredeneerd heeft het MAC adres waaraan het fysieke IP hangt niets te maken met het MAC adres waaraan het virtuele IP hangt. De D-Link zou dat dus kunnen zien als een poging tot spoofen, of de ARP reply simpelweg negeren, omdat de implementatie gewoon slecht is.

Check nog even dat linkje dat ik als eerste postte. De oplossing daar is, vanuit het virtuele IP, met een cronjobje een ping sturen. In dat geval komt gegarandeerd het goede MAC adres aan bij de switch.
Misschien biedt dat in jouw situatie ook soelaas.
(Dit linkje dus: https://forum.pfsense.org/index.php?topic=66838.0)

[Glashelder]

Via telnet is inderdaad de ARP tabel uit te lezen en daar komt het virtuele ip adres niet tussen te staan.

Ik kan morgen wel een screenshot maken van de wireshark dump maar er staat alleen maar 'who is at 192.168.212.254?' waarop mijn firewall antwoord met '192.168.212.254 is at «mac»' , precies zoals je zou verwachten

En pingen vanaf de firewall met het virtuele ip adres als source heeft alleen maar een ARP requests van de d-link tot gevolg (waarop de firewall gewoon netjes antwoord geeft). Een reply op de ping komt niet..

[anboni]

Dit gaat alleen maar over de management interface van die switches, als ik het goed begrijp? Nou snap ik de drang om een dergelijk probleem te willen snappen (dit soort vraagstukken heb ik ook al heel wat uurtjes aan besteed ), maar als het er alleen maar om gaat dat je die switch wilt kunnen managen/monitoren, dan is er toch niet zo'n heel groot probleem om die switch z'n gateway maar naar 1 van de pfsense dozen te laten wijzen? Als die er uitligt, heb je even geen monitoring op je switch, maar je weet snel zat dat dat daar aan ligt.

[Bjornski]

Dus, voor mijn begrip;
- je stuurt vanaf de firewall, vanaf het virtuele adres een ping.
- Vervolgens stuurt de switch een ARP request voor het virtuele adres.
- Vervolgens antwoordt de firewall met een ARP reply, afkomstig van weliswaar het verkeerde adres (source-mac van netwerkkaart met fysiek IP), maar met het goede MAC adres in het antwoord.
- Switch doet niets met ARP reply.

In dat geval zijn er twee dingen aan de hand;
- De PFSense firewall zou eigenlijk moeten antwoorden met als source-mac het MAC adres van het virtuele IP. Al zullen de meeste protocol-stacks het gewoon pikken als die ARP reply van een ander mac komt, gok ik. Volgens mij is het niet "fout", alleen "anders". Grote kans dat VRRP bijvoorbeeld hetzelfde doet.

- De switch heeft een bug, of pikt het ARP reply niet vanwege security redenen (wat ik niet geheel vreemd zou vinden).

Staat er iets van een security optie aan in de switch? (Spoofing protectie, broadcast storm protocol, port security, etc. etc.). Zo ja, schakel dat eens allemaal uit.

[Glashelder]

anboni schreef op maandag 10 november 2014 @ 18:03:
Dit gaat alleen maar over de management interface van die switches, als ik het goed begrijp? Nou snap ik de drang om een dergelijk probleem te willen snappen (dit soort vraagstukken heb ik ook al heel wat uurtjes aan besteed ), maar als het er alleen maar om gaat dat je die switch wilt kunnen managen/monitoren, dan is er toch niet zo'n heel groot probleem om die switch z'n gateway maar naar 1 van de pfsense dozen te laten wijzen? Als die er uitligt, heb je even geen monitoring op je switch, maar je weet snel zat dat dat daar aan ligt.

Klopt, zo staat het nu ook ingesteld maar het is wel mega irritant dat zoiets simpels niet werkt Ik heb dit topic eigenlijk voornamelijk gepost om uit te sluiten dat ik iets simpels over het hoofd had gezien..

Bjornski schreef op maandag 10 november 2014 @ 18:04:
Dus, voor mijn begrip;
- je stuurt vanaf de firewall, vanaf het virtuele adres een ping.
- Vervolgens stuurt de switch een ARP request voor het virtuele adres.
- Vervolgens antwoordt de firewall met een ARP reply, afkomstig van weliswaar het verkeerde adres (source-mac van netwerkkaart met fysiek IP), maar met het goede MAC adres in het antwoord.
- Switch doet niets met ARP reply.

In dat geval zijn er twee dingen aan de hand;
- De PFSense firewall zou eigenlijk moeten antwoorden met als source-mac het MAC adres van het virtuele IP. Al zullen de meeste protocol-stacks het gewoon pikken als die ARP reply van een ander mac komt, gok ik. Volgens mij is het niet "fout", alleen "anders". Grote kans dat VRRP bijvoorbeeld hetzelfde doet.

- De switch heeft een bug, of pikt het ARP reply niet vanwege security redenen (wat ik niet geheel vreemd zou vinden).

Staat er iets van een security optie aan in de switch? (Spoofing protectie, broadcast storm protocol, port security, etc. etc.). Zo ja, schakel dat eens allemaal uit.

Je beschrijving klopt inderdaad. Dit is wat Wireshark oppikt tijdens een ping

code:

[2.1.5-RELEASE][root@pfsense01.<>.nl]/root(1): ping -S 192.168.212.254 192.168.212.110
PING 192.168.212.110 (192.168.212.110) from 192.168.212.254: 56 data bytes
^C
--- 192.168.212.110 ping statistics ---
210 packets transmitted, 0 packets received, 100.0% packet loss

Het "verkeerde" source adres van een ARP reply:



Voor zover ik kan zien staan alle security achtige zaken verder uitgeschakeld.

edit: overigens biedt deze switch voor zover ik kan zien niet de mogelijkheid om een ARP entry handmatig in te voeren.

[Bjornski]

Hmm. Da's redelijk duidelijk denk ik. Als je er 100% zeker van bent dat die ARPs in hetzelfde VLAN plaatsvinden, dan is er denk ik maar één conclusie mogelijk; ietwat brakke protocol stack in de D-Link switches.

Je hebt trouwens kans dat als je de firewall herstart of een failover triggert, dat het de eerste 20 minuten wel werkt. De firewall stuurt een gratuitous arp broadcast bij een failover. Ik vermoed dat dat wel van het goede mac komt, al weet ik dat ook niet zeker.

Misschien kun je nog iets truuken met ArPing. Met ArPing kun je het source-mac opgeven en dat kan dus ook het MAC adres van je virtuele IP zijn. Zie de manpage:
http://www.freebsd.org/cg...ASE+and+Ports&format=html

De FreeBSD port van ArPing zit volgens mij standaard in PFSense.

[serkoon]

Wellicht is de informatie op https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141023 ook nog wel interessant (een bij FreeBSD aangemelde bug over het verschil tussen source mac van de arp reply en de mac in de arp header zelf).

[ Voor 34% gewijzigd door serkoon op 11-11-2014 13:33 ]