Multi-Wan IPV6
-
Hi All,
I've got an interesting setup that I'm trying to refine - looking for any information from people who may have tried this before.
So I have two WAN connections into the premises which are configured and working OK. One WAN connection provides me Static IPV6, which is fine - the other WAN ISP doesn't provide IPV6 yet.
What I'm finding is when my 'IPV6' ready connection drops, the internet becomes very sluggish. It seems as if I'm still trying to route to IPV6 content but as my IPV6 'isp' is down, it can't get there. It will load eventually, but it doesn't really give the impression of a seamless failover!
So has anyone experienced similar before, and what are people’s recommendations going forward? Ideally I'd want to either have two IPV6/IPV4 gateways together, so if one connection goes down the other will continue to carry all traffic. Or alternatively, when my IPV6 connection goes down for my firewall to stop resolving IPV6 traffic and throw everything @ my IPV4 ISP.
I've read up about IPV6 tunnels/VPN, to fill the void left by an ISP which doesn't provide IPV6 - is that something which works well in practice?
Appreciate any info or feedback.
Cheers,
-
Unfortunately there isn't a way to make pfSense drop the router advertisement on the inside if an outside interface goes down. That means the clients will all still think they should have IPv6 connectivity but it will be broken. The delay you are seeing is likely the application attempting to connect IPv6, failing (which takes time), and falling back to IPv4.
You might be able to bring up an HE.NET tunnel using the second WAN and policy route IPv6 only to a gateway group containing the main WAN and the Tunnel.
Note that you will have to set up NPt (prefix translation) for the ISP address to the HE.NET tunnel addresses since you will not be able to route out HE.NET sourced from the ISP addresses. I would reserve the first /56 out of your HE.NET /48 for this purpose (he-net-prefix:0000:: through he-net-prefix:00ff::). I would do this even if you only get a /60 from your provider. They might gain a clue someday.
True Multi-WAN for IPv6 will require significant client support because it will need to make routing decisions and source from the correct address to the correct advertised router based on what it knows or there will have to be some NPt compromise made, such as NPt from ISP prefix to HE.NET prefix or using ULA internally and NPt to both. I would probably choose the former.
-
Just playing devils advocate here. What is IPv6 getting you actually - is there some resource(s) that is only available via ipv6? Since your having a problem with your failover solution, wouldn't it just be easier solution to just not use ipv6.
While we all agree ipv6 is the future, and yeah its kewl and slick and all. Seems to me you have highlighted one of the many pitfalls that comes with trying to run dualstack. So unless you can state an actual use case that requires your ipv6 connectivity. Wouldn't the simple solution to guess something that happens now and then and not once in a blue moon.
-
Thanks for the replies.
@Derelict - I've actually done as suggested, two load balanced gateway groups (1 ipv4, 1 ipv6). My HE.NET tunnel works....but getting pfsense to use it when my primary IPV6 is down isn't going to plan...my guess is that the NPt isn't working correctly.
I'll admit my IPV6 knowledge isn't amazing, I've only recently started dabbling in it. When that NPt rule is enabled, I get stacks of errors along these lines -
There were error(s) loading the rules: /tmp/rules.debug:78: syntax error - The line in question reads [78]: binat on $HENETV6 inet6 from to any ->@johnpoz I know what you mean, I think it's just something new to learn from my point of view. Something to say I've done and works....doesn't really serve me a great purpose, but more of a nice to have and a nice to play with.
-
Ok if your just playing with it - GREAT!... Are your users complaining? If not or you don't mind then yeah take the opportunity to learn for sure.. Derelicts solution would be the way I would do it if needed to do something like this.
Or just use the HE tunnel through both connections, and let the tunnel move over to your other isp when/if the first isp fails.
This removes the need to do any Npt.. Since your clients will always just have your HE network and your just taking using different path to setup the tunnel over the other ISP when the first ISP goes down. You might need to have the tunnel updated to reflect your different source IP.
-
@crucialguy said in Multi-Wan IPV6:
/tmp/rules.debug:78: syntax error - The line in question reads [78]: binat on $HENETV6 inet6 from to any ->
Well that certainly doesn't look right. What did you put for the NPt settings?
-
cheers @johnpoz - that's a good call actually, a much cleaner way of achiving what I'm trying to do.
I'm not worried about users, this is on a lab setup at the moment - so I can play around to my hearts content.
-
@derelict - so on my rule It's following interface 'WAN2' which doesn't have IPV6. The first address/profiix is what my ISP has allocated me and I distribute to my LAN clients
The destination prefix is my routable one from HE.net....if that's right. As I said, my IPV6 knoweldge is in the early days so please bear with me!
Attached is a screen grab...(I've probably made a basic mistake somewhere)
https://ibb.co/jisjky
-
You would need two policy-routing gateway groups and rule sets. one for IPv4 and one for IPv6.
IPv4
WAN Tier 1
WAN2 Tier 2IPv6
WAN Tier 1
HENET Tier 2Then you would policy route IPv4 to the IPv4 gateway group and IPv6 to the IPv6 gateway group.
/tmp/rules.debug:78: syntax error - The line in question reads [78]: binat on $HENETV6 inet6 from to any ->
None of that has anything to do with that broken rule you posted however. What is in the NPt settings for that?
-
@derelict my NPt rule is here -
I've got the two policy-routing groups setup, it's just the NPt routing which is stopping it from working I think.
-
The interface should not be WAN2. The interface should be the HE.NET tunnel.
Sorry missed the external link to the image. You can just post them locally so they're easier to see.
-
@derelict doh'
I knew it would be something as dumb as that! Jeez.
Thanks a lot to everyone for your help.
it works now :) !!
