IPv6 Routing

JKnott

I don't use ULA myself so I didn't test it any further.

I don't think the link local issue has anything to do with ULA.

IsaacFL

@IsaacFL said in IPv6 Routing:

I don't use ULA myself so I didn't test it any further.

I don't think the link local issue has anything to do with ULA.

I was trying to set up an interface using ULA as the prefix connected on layer 2 to another interface with a GUA prefix. That way a service such as DNS could get a ULA address in addition to its GUA. This is a valid use case for ipv6 as you can have multiple prefixes in a single link.

Having the same Link Local Address on both of the pfsense interfaces, caused problems as this gave me 2 different MACs both claiming to be using fe80::1:1.

JKnott

@IsaacFL

I think you're getting issues mixed up. I was responding to your comments about the link local address always being fe80::1.1, which prevented having more than 1 pfSense box on a network. That has nothing to do with ULA. ULA works and I have it set up here. My computer, which I'm typing on right now, has both ULA and GUA addresses. Here is one of the ULA on it: fd48:1a37:2160:0:14ad:9c43:189d:fb77. It also has GUA, so I can go out to the internet.

IsaacFL

@JKnott
It was maybe a year ago I tried it so maybe they fixed it. At the time pfSense would not advertise a 2nd prefix on the same interface and trying to use a second interface to advertise a 2nd prefix failed because of the duplicate link local. Two separate Mac addresses both claiming the same ip address.

But I haven’t tried it with 2.4.5 so maybe it is fixed.

IsaacFL

@JKnott

I did check and the issue I had that led me to try 2 interfaces is fixed. Not using ULA's today:

I was able to add a spare /64 to the RA of one of my interfaces.
I verified that it created the proper entry in the /var/etc/radvd.conf
A test pc did receive an additional address from the added prefix
First ping did not work.
Noted that pfsense did not automatically create a route for the new /64
Created a VIP with an address in the /64 which did create the route
Ping worked.

So that is all good now. Could be more automatic but it works.

But that is not a real common usage of multihoming (ULA excepted). More common would be the case where for redundancy you have 2 ipv6 routers, each advertising a different /64. connected to the same layer 2. This I don't think would work with pfsense, because of the hard coded fe80::1:1 on the LAN interfaces when connected to the same layer 2.

I don't really have a way to try that out currently as I would have to create a virtual pfsense, etc. and with stay at home, Dear Spouse would probably not consider me so dear.

I could write a bug report for it, but I don't have an easy way to test.

IsaacFL

@JKnott

Wait, the dual prefix setup did not survive a reboot.
I remember now, the bug is that IPv6 VIP overwrites the prefix that should be provided from the track id.

So how do you get ULA to work on pfsense and survive a reboot?

JKnott

@IsaacFL

I have been using ULA for well over a year. However, one thing I found is that the GUA prefix was no longer automatically assigned. I had to manually add both the ULA and GUA prefixes on the Router Advertisement page.

JKnott

@IsaacFL

You seem to be bouncing all over and making it hard to figure out what you're doing. ULA works, as I have here. Multiple interfaces work, as I have done here. The LAN link local address appears to be broken, as it should never try to force fe80::1:1. According to that RFC, duplicate address detection is supposed to be used.

IsaacFL

@JKnott said in IPv6 Routing:

@IsaacFL

You seem to be bouncing all over and making it hard to figure out what you're doing. ULA works, as I have here. Multiple interfaces work, as I have done here. The LAN link local address appears to be broken, as it should never try to for fe80::1:1. According to that RFC, duplicate address detection is supposed to be used.

The other things were just what led me to the last thing

The LAN link local address broken is the only thing I am concerned about as it keeps me from trying out multihoming with multi routers.

q54e3w

@JKnott said in IPv6 Routing:

@IsaacFL

I have been using ULA for well over a year. However, one thing I found is that the GUA prefix was no longer automatically assigned. I had to manually add both the ULA and GUA prefixes on the Router Advertisement page.

I’ve been thrown a loop with these interfaces changing on me, could you add a picture of your VIPs and RA pages please? I’be tied myself up in knots over the prefix size which I thought I had right, but folowing a reboot I’m not sure it was ever right. Thanks for useful posts elsewhere on IPv6 they’ve been useful.

Edit: ah, I think I’ve hit the issue around the interface addresses that reorder after a reboot that’s reported on Redmine.

JKnott

@q54e3w

Hers's the RA page. I had to include the prefix from my ISP, as for some reason pfSense doesn't do that when you use ULA

And the VIP page

IsaacFL

@JKnott

Wouldn't this break though if your ipv6 prefix changed dynamically? Any devices on this interface would lose internet connectivity via ipv6.

I thought the only point of trying to use the ULA address, was to try to keep connectivity to things like external DNS, etc. if the prefix changed.

It seems that the real bug here, is that a route isn't automatically added when the subnet is added. If that was done, you wouldn't have to use a VIP which brings in its own issues.

Also are both of these subnets included in "LAN net"?

q54e3w

@JKnott Thank you. I was on the right track and not totally closing my mind.
@IsaacFL My understanding is these workarounds are partly to help mitigate the issue here

JKnott

@IsaacFL

The prefix should not be changing. There's a setting to prevent pfSense from releasing the prefix, though, apparently, some ISPs don't comply. When I first started using pfSense, that setting wasn't available and my prefix did change for something as minor as disconnecting/reconnecting the WAN cable.

IsaacFL

@JKnott said in IPv6 Routing:

@IsaacFL

The prefix should not be changing. There's a setting to prevent pfSense from releasing the prefix, though, apparently, some ISPs don't comply. When I first started using pfSense, that setting wasn't available and my prefix did change for something as minor as disconnecting/reconnecting the WAN cable.

My prefix doesn't change either, which is why I don't use ULA. Not sure of the point of ULA in that case.

Are both subnets you have added also get added to the "LAN net" for firewall rules?

JKnott

@IsaacFL

The ULA addresses are not routed off my network, so there's no need for rules. ULA addresses are routeable, just like RFC 1918 on IPv4, but are not allowed on the Internet. You can use ULA in the same way as you might RFC 1918, except you can have both ULA and GUA addresses on the same network. One reason might be you still have local networking, even if your ISP connection fails.

q54e3w

@JKnott Thats exactly how I (would like to!) use my ULAs to ensure locally hosted services still function when my WAN connection goes down as that takes out all the GUA's across local subnets.
The family won't care about IPv6 blah blah if Emby isnt working.

IsaacFL

@JKnott
Ok, I can see then why you would use ULA for that.

I don't know FreeBSD, but isn't there a route command to just add the static route to the interface without creating a VIP?

You don't need a VIP since the gateway for both of these subnets is going to be fe80::1:1 anyway. If you look at the RA it is advertising itself for both subnets on the link local.

JKnott

@IsaacFL

Yes, I know the RA has both. People have to get away from the IPv4 way of thinking. There are essentially unlimited addresses available. You can have multiple addresses on an interface. In my case, I have link local, GUA and ULA. I could even have multiple GUA & ULA if I wished. Sometimes you just want a local network for some devices that share the same network as the devices that connect to the Internet. As mentioned, there is an issue with pfSense where it forgets to apply the GUA prefix, when ULA is also used. As far as I'm concerned, that's a bug.