pfsense 2.4.4p3 - IPv6 on bridged interfaces not working...
-
Hi,
I have a setup of 4 NICs firewall, which one interface goes to WAN, 3 others are bound as BRIDGE0 (but interface BRIDGE0 not assigned!) - LAN, LAN2, LAN3 interfaces.
While this setup works perfectly for IPv4, the configuration for DHCP/IP is on LAN interface and is nicely distributed to LAN2, LAN3 interfaces.
IPv6 seems to work only on LAN interface connected devices - they get IPv6 addresses, prefixes are properly distributed, all routing and traffic goes perfectly fine. I'm using He.net service, so GIF interface is on, I have /48 assigned and I did subnetting on it to /110 prefixes.
Devices connected to LAN2 and LAN3 get nothing related to IPV6, but some icmpv6 is observable on the firewall and allowed. No DHCPV6 leases assigned, no traffic comes out. I triplechecked firewall rules, DHCPV6 setup, RAs etc. All is on place.
I have followed many topics here, also this one fix proposed
I also did an experiment - added static IPV6 config to LAN2 and LAN3 interfaces with separate IPv6 subnets for them (/110 prefix) - it seems to work but I would say it is random behavior, some hosts do get IPV6, some not, sometimes I see 2-3 link local addresses on the interface... This is expected as we are trying to do something counter-intuitive (putting L3 config on L2 bridge subinterfaces - wrooong)
I think it should work just with LAN (which is def gw for whole bridge) interface configured.
Should I assign BRIDGE0 interface under interfaces->assignments and then move all IPv4/IPv6 config there? I don't think it is needed - I need L2 bridge of 3 interfaces acting as plain switch and do all L3 config on one of them (called LAN)
Any ideas? I'm scratching my head but can't figure out what is wrong ....
EDIT: it seems to work well only when at least /64 is being assigned and slac mechanism can work. DHCPv6 doesn't work still.....
-
you should always use a /64 on interfaces
SLAAC only works with /64 for example
edit : you found out yourself when i was writing.he.net give you /48 you must assign /64 prefix out of the /48 to your interfaces
be sure to set /64 even on dhcpv6 server & ra
-
Yes, changing to /64 causes to slac to kick in but DHCPV6 still not working, even with /64 assigned. And this is not mandatory to choose /64 - you can split /48 as much as you wish, routing is done on he.net to whole /48.
-
make a screeshot of your dhcpv6 server and interfaces eventualy me and @johnpoz have he.net ipv6 configured on our pfsense and it's working without problem, must be some misconfiguration somewhere
ps: that fix is really really old
-
fix is old, but without it, there is no link-local addresses for interfaces on the bridge.... and nothing will virtually work at all in that kind o setup.
Comparing your screens, this is exactly the same setup. Just keep in mind that my "primary" interface LAN has all IP information needed, while LAN2 and LAN3 are bound with LAN as BRIDGE0 (pure L2 bridge, no L3 config)
-
ah i understand
i was checking the process
dhcp is launched like this/usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid ix0 ix0.30 ix0.20 ix0.100 igb1my guess is that it's not serving your LAN2 / LAN3 but only LAN even if it's set as a L2
but than again.. if it was that, you should have problem even with ipv4 ....
let's see what we can find out until someone come to the rescuedid you try any packet capture ?
-
advanced configuration of the bridge
-
@kiokoman it is set, but it doesn't do anything than set the flag "auto linklocal" (patch to make link local address is STILL needed!)
-
i'm replicating your config on my virtual machine, i have the same behavior.
ipv4 work on all interface, ipv6 only on LAN -
i get an adress if i configure a /64 but dhcpv6 still not working idk if it's a bug or what
-
@kiokoman exactly. Only slac works and only for /64 prefixes (which is obvious) DHCPv6 works only on first interface of the bridge
-
i can't find a way out ...
what i found with packet capture is that there is no answer from dhcp
from console i use struss against the running dhcp. it see request coming from dhclient -4 but it see nothing coming from dhclient -6 -
@kiokoman when you assign shorter network for each one of the interfaces from the bridge it will work. But will work randomly. This is apparently a bug but...
-
Interfaces get a /64. Anything else is nonsense.
-
yes, well i was testing with prefix set to /64 for the interface but i don't understand why dhcpv6 is unreacheable
-
Yes, despite the prefix set (/64 or any else) DHCPv6 doesn't work over bundled interfaces. It should normally as it does for DHCPv4. I have floating rule allowing all traffic in the lan area so it is no issue either here...
BTW, shorter prefixes are used widely in the enterprises, this is not nonsense.
-
@tomeq82 said in pfsense 2.4.4p3 - IPv6 on bridged interfaces not working...:
BTW, shorter prefixes are used widely in the enterprises, this is not nonsense.
Not on the LAN, where /64 must be used. The shorter prefixes are split by routers, eventually winding up at /64s. For example, I get a /56 from my ISP, which I can split up into 256 /64s. I could, if needed, spit it into other prefixes, for routing elsewhere, before getting to the /64s.
-
@JKnott Correct, nevertheless - in this scenario it doesn't really matter. /64 is not hard limit in any kind (only if you use SLAAC it is "must")
-
@tomeq82 said in pfsense 2.4.4p3 - IPv6 on bridged interfaces not working...:
@JKnott Correct, nevertheless - in this scenario it doesn't really matter. /64 is not hard limit in any kind (only if you use SLAAC it is "must")
From RFC4291
" For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format." -
@tomeq82 well aware that interfaces may be set to prefixes longer than /64 in certain router-to-router links, etc. That is not what is being discussed here. Interfaces with hosts on them need to be /64.
-
N netblues referenced this topic on
-
N netblues referenced this topic on
-
N netblues referenced this topic on
