Gelöst: Router findet VIP (CARP) nicht (ARP problem?)

[endurance]

Moin,

nutze schon eine Weile OPNSense wollte jetzt jedoch ein HA setup mittel CARP VIP erstellen. Also eine zweite OPNsense FW angeshafft.
Die FW sind je an zwei WAN Routern angeschlossen. Problem ist, dass die Router die VIP aus mir nicht erklärbaren Grund NICHT finden (für die Portweiterleitung von einkommendem Verkehr).

Code: [Select]

      Router 1 192.168.88.1/24                                            Router 1 192.168.89.1/24
                          |                                                             |
                VIP 192.168.88.5/24                                           VIP 192.168.89.5/24
                  |            |                                                 |        |
OPNS 1 192.168.88.2/24  OPNS 2 192.168.88.4/24                OPNS 1 192.168.89.2/24  OPNS 2 192.168.89.4/24                   
   

Router und OPN jegen je an einem kleinen 5 Port Switch.

Nutze ich die 88.2 oder 89.2 (bzw. 88.4 oder 89.4) als NAT Ziele von den Routern funktioniert es wunderbar. Aber dann nützt mir die CARP VIP nichts. Trage ich die VIP als Ziel ein findet der Router die IP nicht.

Ich habe zur Diagnose mal einen Raspi mit auf den Switch geschaltet:

Code: [Select]

22:32:28.316494 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
22:32:29.316065 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
22:32:30.316307 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
22:32:45.283384 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
ARP Anfragen vom Router werden nicht beanwortet.

Hier die ARP Tabelle vom WAN Router 192.168.88.1/24:

Code: [Select]

192.168.88.2      3C-EC-EF-25-A7-5B                                LAN1        VLAN0  P1     
192.168.88.4      3C-EC-EF-AA-5A-4D                                LAN1        VLAN0  P1       
192.168.88.50     E4-5F-01-96-17-37                                LAN1        VLAN0  P1

50 ist der RASPI. Der Raspi hat einen ARP eintrag zur OPN und wenn ich den lösche und die VIP Pinge kommt

Code: [Select]

22:35:37.172102 ARP, Request who-has 192.168.88.5 tell 192.168.88.50, length 28
22:35:37.172183 ARP, Reply 192.168.88.5 is-at [b]00:00:5e:00:01:02[/b] (oui IANA), length 46
Also die MAC der VIP kommt zurück.
Warum klappt das mit der VIP und dem Router nicht? Hat mir da jemand einen Tipp - sitze da jetzt gerade echt auf dem Schlauch

Oder eine andere Lösung wie man Active/Backup konfigurieren kann.

Anmerkung: Auf der LAN Seite funktioniert die CARP VIP problemlos.

 

[mimugmail]

Ich glaube die 5Port Switches filtern die Pakete. Kannst du testweise einen anderen nehmen oder ins LAN und schauen ob der Ping geht?

[endurance]

Vom LAN aus geht der Ping - der RASPI hängt an dem selben Switch wie der Router. Zwischen Router und Switches ist nichts als ein Kabel. Ich habe testhalber auch mal eine FW direkt mit dem Router verbunden - das hilf auch nichts. Ping/traffic auf die IP geht aber auf die VIP nicht.

[mimugmail]

Kannst du die Verkabelung kurz aufzeichnen? Kann eigentlich nicht sein.

Die Subnetzmaske von der VIP ist identisch wie die physikalische Netzmaske?

[endurance]

Verkabelung ist sehr einfach quasi gleich dem Bild das ich in ASCI im Ersten post gemacht habe.
Statt der VIP den Switch vorstellen. Sprich je ein Port der OPN am Switch und von dort dann ein Kabel zum WAN Router.

Code: [Select]

      Router 1 192.168.88.1/24                                            Router 1 192.168.89.1/24
                          |                                                             |
                      Switch 1                                                     Switch 2
                  |            |                                                 |        |
OPNS 1 192.168.88.2/24  OPNS 2 192.168.88.4/24                OPNS 1 192.168.89.2/24  OPNS 2 192.168.89.4/24                   
   

Dass dann symmetrisch für beide WAN strecken.

Sind alles /24 Subnetze - im ersten Posting hatte ich an einer VIP /25 geschrieben das war ein Typo.

Jetzt habe ich mal einen BanaPi (Ubuntu) als switch eingebaut. Nur um mal den Netgearswitch auszuschließen
Dassselbe Bild der Pi findet die VIP und trägt dann die MAC brav in seine ARP table ein. Der WAN Router weigert sich standhaft (aber der Ubuntu Pi steht jetzt drin - funktioniert also prinzipiell schon).
Hab echt keine Idee mehr. Könnte jetzt noch den PI in einen Router umwandeln und verschiedene Netze Verwenden, aber so recht sinn macht das jetzt vom eigentlich setup her nicht.

Code: [Select]

pi@bpi-iot-ros-ai:~$ sudo arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.89.2             ether   3c:ec:ef:e9:7c:1b   C                     eth0
192.168.89.1             ether   14:49:bc:0a:7d:38   C                     eth0
pi@bpi-iot-ros-ai:~$ ping 192.168.89.5
PING 192.168.89.5 (192.168.89.5) 56(84) bytes of data.
64 bytes from 192.168.89.5: icmp_seq=1 ttl=62 time=0.696 ms
64 bytes from 192.168.89.5: icmp_seq=2 ttl=62 time=0.771 ms
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.696/0.733/0.771/0.046 ms
pi@bpi-iot-ros-ai:~$ sudo arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.89.2             ether   3c:ec:ef:e9:7c:1b   C                     eth0
192.168.89.5             ether   00:00:5e:00:01:03   C                     eth0
192.168.89.1             ether   14:49:bc:0a:7d:38   C                     eth0
pi@bpi-iot-ros-ai:~$ sudo tcpdump arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:34:13.836225 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
...
00:34:24.620613 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
00:34:33.527139 ARP, Request who-has 192.168.89.1 tell 192.168.89.51, length 28
00:34:33.529200 ARP, Reply 192.168.89.1 is-at 14:49:bc:0a:7d:38 (oui Unknown), length 46
00:34:58.991837 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
...
00:35:09.618950 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
00:35:30.119232 ARP, Request who-has 192.168.89.51 (0e:5f:b1:1e:2f:54 (oui Unknown)) tell 192.168.89.1, length 46
00:35:30.121295 ARP, Reply 192.168.89.51 is-at 0e:5f:b1:1e:2f:54 (oui Unknown), length 28
00:35:40.527160 ARP, Request who-has 192.168.89.1 tell 192.168.89.51, length 28
00:35:40.529282 ARP, Reply 192.168.89.1 is-at 14:49:bc:0a:7d:38 (oui Unknown), length 46

[endurance]

Noch jemand eine Idee?
Kann es einen UNterschied machen ob der ARP request vom Gateway kommt oder von einem anderen Device/IP?
Der WAN Router ist ja als Gateway in OPNSense drin - werden Anfragen vom Gateway evtl. besonders behandelt?

[endurance]

Hätte evtl. ja schon selber mal auf die Idee kommen können auf der betreffen OPNsense selber ein TCPDump laufen zu lassen

Code: [Select]

root@OPNsense-One:/dev # tcpdump -i igb1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), capture size 262144 bytes
20:02:32.568142 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
20:02:32.568146 ARP, Reply 192.168.88.5 is-at 00:00:5e:00:01:02 (oui IANA), length 28
Also schickt die FW die Antwort auch raus. Das der Pi und co die nicht sieht macht ja auch Sinn, da Switch dazwischen (kein Hub - hatte ich auch mal gelernt vor langer Zeit). Aber warum trägt der WAN Router die MAC der VIP nicht in seine ARP table ein? Das der Switch die verschluckt glaube ich nicht dann müsste er das Richtung PI auch machen. Bleibt noch der Router selber, der die MAC verwirft. Oder sieht jemand noch etwas anderes?

Update wenn man mal scharf Nachdenkt:
Defense setup im WAN Router: Block ARP replies with inconsistent source MAC addresses.
Wenn man die Prüfung raus nimmt funktioniert der Traffic. ABER die MAC wird trotzdem nicht eingetragen und es kommt eine kurze flut von ARP requests.
Mit filter an kommt auch im syslog des Routers (wenn man den Filter kennt kann man auch das logging dazu einschalten:)):
 2022-12-19 20:23:58    Arp address mismatch - Ethernet source address doesn't match ARP sender address

Also ist jetzt die Fragestellung was muss ich evtl. an der OPNSense ändern, damit die DefenseRule nicht zuschlägt.
laut arp table auf dem Router: 192.168.88.2      3C-EC-EF-25-A7-5B
Die OPNsense antwortet aber mit:
3c:ec:ef:25:a7:5b > 00:1d:aa:70:09:08, ethertype ARP (0x0806), length 42: Reply 192.168.88.5 is-at  00:00:5e:00:01:02, length 28
Das hier die MAC der Quelle ungleich beantwortetes Ziel ist meckert der Router denke ich zurecht an oder?

Wenn man die Regel bzgl VRRP ARP darf nicht eingetragen werden auch noch rausnimmt, steht die MAC dann endlich auch im Cache. Also Problemstellung denke ich gelöst.

[mimugmail]

Hab doch geschrieben der Switch filtert das

[endurance]

Ja fast - war halt der fragende WAN Router (nicht der switch dazwischen) - aber schöner wärs, wenn OPNSense auch die SRC MAC entsprechend setzen würde oder sehe ich das falsch?

[Patrick M. Hausen]

Nein, sie benutzt eine VRRP MAC. Wenn du deinen Router ausdrücklich anweist, die zu filtern, dann klappt's halt nicht.

CARP benutzt Protokoll-Nummer und MAC Adressen VRRP - Guerilla-Taktik der OpenBSD-Leute, würde ich sagen.

[endurance]

>Wenn du deinen Router ausdrücklich anweist, die zu filtern, dann klappt's halt nicht.

Default setting. Macht ja evtl. auch Sinn. Erfahrung macht klug 
Evtl. sollte man dass gleich in die Howtos für dummies mit reinnehmen

[Patrick M. Hausen]

Warum hast du Firewall-Funktionen auf dem Router vor deiner Firewall an? Der soll routen und sich raushalten. Ich hab so ein Gerät ehrlich noch nie gesehen. Router routen, Switche switchen, Firewalls firewallen ...

[endurance]

Hinter dem Draytek hängen "unsichere" Geräte und ich hatte das auch mal in Kombi mit Draytek Modems betrieben (mittlerweile wieder Fritzboxen weil das die Provider leider so wollen sonst nicht vernünftig supporten)

Also:
Internet - Modem - exposed host -> Draytek --- IOT und WIFI für Gäste
                                                                  - dedizierte Portweiterleitung -> OPNSense  --- LAN