Question regarding DHCPv6 on a Multi WAN setup
-
Bonjour, tout le monde.
I don't want to appear rude, but I'll get straight to the point: I've enabled DHCPv6 on both our WAN interfaces (same ISP, same GW), but after rebooting pfSense only one (sometimes the first one, sometimes the second one) will get an IPv6 address assigned. Why is that?
[[s]Also I'm not exactly sure how one would distribute non-static IPv6 addresses within the LAN. Is there a tutorial on this topic out there? Edit: Okay, I just set the IPv6 address of my pfSense box to fd…1/64 and enabled DHCPv6 on the LAN interface. That worked like a charm.]
I'm running pfSense-LiveCD-2.1-RELEASE-amd64-20130911-1816 (no VM).
Many thanks in advance.
-
both our WAN interfaces (same ISP, same GW)
There's your problem. You can't have two interfaces in the same subnet with the same gateway or only one of them will get a link route to the subnet/gw, and if traffic tries to exit the other it just dies.
-
both our WAN interfaces (same ISP, same GW)
There's your problem. You can't have two interfaces in the same subnet with the same gateway or only one of them will get a link route to the subnet/gw, and if traffic tries to exit the other it just dies.
I very appreciate your answer, but I was somehow hoping for a solution there. Like is there a workaround for this problem? :(
-
It's the same on IPv4 as IPv6 - you'd need some other router in between to change the subnet, but that isn't quite so simple with IPv6 and a dynamic allocation. There are many discussions here and elsewhere about how to overcome the issue on IPv4.
-
Thanks again for replying! I really appreciate it!
I've set up three copies of pfSense 2.1 running smoothly within virtual environments (using VMware ESXi 5.5) like so…
pfSense #1:
WAN0 (DHCP; DHCPv6),
INT0 (192.168.10.1, 192.168.10.0/30; fc00::1, fc00::/126)pfSense #2:
WAN1 (DHCP; DHCPv6),
INT1 (192.168.11.1, 192.168.11.0/30; fc01::1, fc01::/126)pfSense #3:
INT0 (192.168.10.2, 192.168.10.0/30; fc00::2, fc00::/126),
INT1 (192.168.11.2, 192.168.11.0/30; fc01::2, fc01::/126),
LAN0 (192.168.0.1, 192.168.0.0/24 DHCP; fcff::1, fcff::/64 DHCPv6)with
WANn being the connections to the cable modems,
INTn being the connections to virtual switches and
LAN0 being the connection to an unmanaged switch and ultimately to the workstations.pfSense #1 and pfSense #2 are set to allow any IPv4+IPv6 traffic.
IPv4 does work just like I wanted it to, some very efficient load-balancing going on.
IPv6 does not work: Workstations will get an fcff::/64 IPv6 assigned and they can get to pfSense #3's WebUI by using [fcff::1]:80, but [fc00::1]:80, [fc01::1]:80 and any IPv6 website tested will simply time out.I don't know, I just hoped pfSense (#1 and #2) would magically route all the (pfSense #3) IPv6 traffic.
-
pfSense #3 INT0 and INT1 are like WANs to pfSense #3 - I expect they have a gateway set, like 192.168.10.1 and 192.168.11.1. For IPv4 pfSense will be doing Automatic Outbound NAT on those. Thus a ping from LAN to 192.168.10.1 will be NATed and seen as comin from 192.168.10.2 - 192.168.10.1 knows how to reply to that.
But for IPv6 there is no Outbound NAT. Any upstream routers have to know how to fully route the network. So #1 and #2 would need to have static routes to tell them about the existence of LAN IPv6 behind #3. -
Thank you, too, for replying.
So #1 and #2 would need to have static routes to tell them about the existence of LAN IPv6 behind #3.
But how would one do that? Setting a LAN interface (INT0 on pfSense #1 / INT1 on pfSense #2) as gateway for static routes isn't possible.
- he said and slowly began to realize that a consumer grade multi-wan router would be a more appropriate solution for him.
-
I just tried on a test system and you should be able to do similar on yours, e.g. pfSense#1 will already have an IPv6 address that you gave it on INT0
System->Routing
Add a gateway of type IPv6, interface INT0 and the IPv6 of #3 INT0
Routes tab
Add a static route to LAN0 IPv6 subnet through the gateway you just madeThat seemed to produce a sensible routing table in Diagnostics->Routes - I can't see if my test really works, but it should.
-
I just tried on a test system and you should be able to do similar on yours, e.g. pfSense#1 will already have an IPv6 address that you gave it on INT0
System->Routing
Add a gateway of type IPv6, interface INT0 and the IPv6 of #3 INT0
Routes tab
Add a static route to LAN0 IPv6 subnet through the gateway you just madeThat seemed to produce a sensible routing table in Diagnostics->Routes - I can't see if my test really works, but it should.
You are right, I will give this a go at the weekend. Thank you again!
It's the same on IPv4 as IPv6 - you'd need some other router in between to change the subnet, but that isn't quite so simple with IPv6 and a dynamic allocation. There are many discussions here and elsewhere about how to overcome the issue on IPv4.
This is not the case.
Let's assume we have only one pfSense router with WAN0 and WAN1…
IPv4:
- Both interfaces get their addresses via DHCP out of the same subnet and get routed over the exact same (physical) gateway.
- The gateway group of WAN0_DHCP and WAN1_DHCP will load balance traffic.
- When alarm goes off for WAN0_DHCP, all traffic gets routed over WAN1_DHCP.
IPv6:
- Only one (seemingly random) interface gets an address via DHCPv6.
I see that without NATing load balancing wouldn't work like that anyway for IPv6, but even without the intention of doing anything with the second line, shouldn't both interfaces get IPv6 addresses assigned by the DHCPv6 server? :-\
-
Your IPv4 case only works by accident. It's not supported to use them in that way. Two interfaces in the same DHCP scope may pull multiple addresses but the routing will be a mess in reality. You can't count on the same broken scenario to work in IPv6 because it just happens to work in IPv4. The documented/supported behavior (and by consequence, limitations) are the same in this case.
-
Your IPv4 case only works by accident. It's not supported to use them in that way. Two interfaces in the same DHCP scope may pull multiple addresses but the routing will be a mess in reality. You can't count on the same broken scenario to work in IPv6 because it just happens to work in IPv4. The documented/supported behavior (and by consequence, limitations) are the same in this case.
But… but everything works in this broken scenario just fine. :'(
The gateway in the rules for some workstations is set to either one of the WANn_DHCP gateways.
-> working as expected: Workstations will just use the gateway I want them to use.The gateway in the default catch all IPv4 rule is set to the load balancing gateway group I created from the WANn_DHCP gateways.
-> working as expected: All other workstations will use the WAN0_DHCP gateway unless an alarm has been triggered. When downloading multiple files or a single file in multiple chunks the bandwidth is being aggregated.How does one see if the routing is indeed a mess, when there's no problems? Traceroutes don't show anything unusual.