Hallo Alle,
ich habe IPv6 und CARP eingerichtet und habe ein seltsames Problem auf der CARP Backup Instanz.
Wenn ich update machen will, versucht die Backup OpnSense natürlich zu erst über IPv6 die Pkgs upzudaten und dies timed aus, somit bekomme ich immer
opnsense-update -V -k
...
(hier dauerts recht lange wegen timeout)
Fetching kernel-25.1.1-amd64.txz: .+ mkdir -p /var/cache/opnsense-update/81289
+ opnsense-fetch -T 30 -q -o /var/cache/opnsense-update/81289/kernel-25.1.1-amd64.txz.sig https://mirrors.dotsrc.org/opnsense/FreeBSD:14:amd64/25.1/sets/kernel-25.1.1-amd64.txz.sig
..............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/81289/kernel-25.1.1-amd64.txz.sig appears to be truncated: 0/1332 bytes]+ exit_msg ' failed, no signature found'
Die "truncated" Meldung bekomme ich jedes mal. Ich kann die Files (sig und kernel) per Hand downloaden und normal installieren aber eben wenn's über IPv4 läuft.
Das lustige ist, wenn ich auf der (!) Master OpnSense, temporär pfctl -d ausführe, dann klappt auch alles über IPv6 auf der Backup OpnSense.
Ich habe schon 3x geprüft, irgendwelche Rules habe ich nicht die IPv6 von der Backup OpnSense verbieten würden. Sonst geht alles normal auf der Master und auch den Hosts dahinter (IPv4 und IPv6).
Habe ich irgendeinen extra "Schalter" vergessen? Kommt jemanden das Problem bekannt vor?
Bin über jeden Hinweis dankbar!
Greetz
hier noch mal die Routen auf beiden Systemen, vielleicht sieht jemand was ungewöhnliches:
CARP Master:
root@cerber:~ # netstat -6 -r
Routing tables
Internet6:
Destination Gateway Flags Netif Expire
default fe80::52e6:36ff:fe UGS vlan0.0004
localhost link#6 UHS lo0
dns.google fe80::52e6:36ff:fe UGHS vlan0.0004
2a02:8106:39:e600: link#11 U vlan0.0004
2a02:8106:39:e600: link#6 UHS lo0
2a02:8106:39:e602: link#3 U vtnet0
cerber link#6 UHS lo0
2a02:8106:39:e604: link#11 U vlan0.0004
2a02:8106:39:e604: link#6 UHS lo0
2a02:8106:39:e605: link#12 U vlan0.0005
cerber link#6 UHS lo0
2a02:8106:39:e615: link#13 U vlan0.0015
2a02:8106:39:e615: link#6 UHS lo0
2a02:8106:39:e624: link#15 U vlan0.1024
2a02:8106:39:e624: link#6 UHS lo0
2a02:8106:39:e648: link#16 U vlan0.2048
2a02:8106:39:e648: link#6 UHS lo0
fe80::%vtnet0/64 link#3 U vtnet0
fe80::be24:11ff:fe link#6 UHS lo0
fe80::%lo0/64 link#6 U lo0
fe80::1%lo0 link#6 UHS lo0
fe80::%lagg0/64 link#10 U lagg0
fe80::a236:9fff:fe link#6 UHS lo0
fe80::%vlan0.0004/ link#11 U vlan0.0004
fe80::192:168:40:2 link#6 UHS lo0
fe80::a236:9fff:fe link#6 UHS lo0
fe80::%vlan0.0005/ link#12 U vlan0.0005
fe80::192:168:50:2 link#6 UHS lo0
fe80::a236:9fff:fe link#6 UHS lo0
fe80::%vlan0.0015/ link#13 U vlan0.0015
fe80::192:168:150: link#6 UHS lo0
fe80::a236:9fff:fe link#6 UHS lo0
fe80::%vlan0.1024/ link#15 U vlan0.1024
fe80::192:168:24:2 link#6 UHS lo0
fe80::a236:9fff:fe link#6 UHS lo0
fe80::%vlan0.2048/ link#16 U vlan0.2048
fe80::192:168:48:2 link#6 UHS lo0
fe80::a236:9fff:fe link#6 UHS lo0
CARP Backup:
root@fenrir:~ # netstat -6 -r
Routing tables
Internet6:
Destination Gateway Flags Netif Expire
default fe80::52e6:36ff:fe UGS vlan0.0004
localhost link#4 UHS lo0
dns.google fe80::52e6:36ff:fe UGHS vlan0.0004
2a02:8106:39:e600: link#9 U vlan0.0004
2a02:8106:39:e602: link#1 U igb0
fenrir link#4 UHS lo0
2a02:8106:39:e604: link#9 U vlan0.0004
2a02:8106:39:e604: link#4 UHS lo0
2a02:8106:39:e605: link#10 U vlan0.0005
fenrir link#4 UHS lo0
2a02:8106:39:e615: link#11 U vlan0.0015
2a02:8106:39:e615: link#4 UHS lo0
2a02:8106:39:e624: link#12 U vlan0.1024
2a02:8106:39:e624: link#4 UHS lo0
2a02:8106:39:e648: link#13 U vlan0.2048
2a02:8106:39:e648: link#4 UHS lo0
fe80::%igb0/64 link#1 U igb0
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%lo0/64 link#4 U lo0
fe80::1%lo0 link#4 UHS lo0
fe80::%lagg0/64 link#8 U lagg0
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%vlan0.0004/ link#9 U vlan0.0004
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%vlan0.0005/ link#10 U vlan0.0005
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%vlan0.0015/ link#11 U vlan0.0015
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%vlan0.1024/ link#12 U vlan0.1024
fe80::20d:b9ff:fe4 link#4 UHS lo0
fe80::%vlan0.2048/ link#13 U vlan0.2048
fe80::20d:b9ff:fe4 link#4 UHS lo0
wenn ich das update starte auf der CARP Backup OpnSense, siehe ich das im Log der CARP Master OpnSense:
>134>1 2025-02-20T15:23:34+01:00 cerber.mgmt.chao5.net filterlog 82363 - [meta sequenceId="24691"] 30,,,02f4bab031b57d1e30553ce08e0ec131,vlan0.0004,match,block,in,6,0x00,0x8a540,120,tcp,6,40,2001:4860:4860::8888,2a02:8106:39:e604::4,853,63203,0,SA,2018633911,114422878,65535,,mss;sackOK;TS;nop;wscale
Die Rule triggert immer auch wenn ich am DMZ Iface (vlan0.0004) eine IPv6 Rule habe die alles erlaubt... HMMMMM
grep 02f4bab031b57d1e30553ce08e0ec131 /tmp/rules.debug
block in log inet from {any} to {any} label "02f4bab031b57d1e30553ce08e0ec131" # Default deny / state violation rule
block in log inet6 from {any} to {any} label "02f4bab031b57d1e30553ce08e0ec131" # Default deny / state violation rule
Wieso triggert da die automatische Rule? Sollte meine explizite IPv6 allow any to any Rule nicht die ausstechen?
Vorallem wieso triggert die auf der CARP Master Opnsense? Wenn ich zum Internet rauspinge (ICMPv6), geht die Kommunikation nicht über die Master CARP Opnsense sondern direkt zum Router hmmmmmmmm