Delegate IPv6 subnet to only specific MAC addresses
-
So if we let IPv6 auto assign to tenant routers, at what point could the subnet assigned to a tenant router change? Obviously if they replace it, but outside of that...?
I'm thinking this might work:
- set building router to hand out IPv6 blocks
- create firewall rule on LAN to only allow IPv6 from known MAC addresses (one rule per MAC)
- create a firewall rule on LAN to assign each subnet to the correct limiter
It's a bunch of extra steps though.
In pfSense how do I find out the subnet a given tenant router is using? Can I connect the Status/DHCPv6 Leases, Delegated Prefixes info to the known MAC?
Option 2 is we set it up for us and wait until someone asks for IPv6. :)
-
Just to follow up, I set it up for us, with static IPv6. It took me longer than I'd care to admit to add firewall rules to allow IPv6 ICMP since we'd never set up IPv6 rules on the building router.
-
@SteveITS Never done it with pfSense but with my first router (fritzbox) towards my pfSense. It says something like this: Allow Ping6, open firewall for the delegated prefix, make this host the exposed host.
-
@Bob-Dig I realized my comment might be unclear so I came back to edit it but you beat me… IPv6 was allowed on the inner router due to the HE tunnel but it had never been allowed outbound on the building/outer router LAN interface since that wasn’t necessary (due to the tunneling).
#ComputersDoExactlyWhatYouTellThemNotWhatYouWant
-
I'm back again. After our Comcast router restarted last night we lost IPv6 to the inner subnet. I am pretty sure it lost the route back. However the Comcast router only allows me to configure an IPv4 static route. Thinking back, possibly it had set up the route while I was experimenting with the various delegation/DHCP settings, and lost it upon restart. Boo.
So I started all over, and set it up using Track Interface and prefix delegation, with the building router DHCPv6 Server set with "Deny Unknown Clients" to allow only known clients. I had to allow any temporarily just to find the DUID of our router.
By the time I got back to set it to allow only known clients again, the building router had allocated another IP and prefix. However, it added a route to this other prefix and would not add a route for our office router prefix. So eventually I gave up and added a static route in our building router, pointing the subnet that had been delegated to our office router, to our office router.
So overall it looks like it should have worked with "deny unknown clients" except there was no route created from the outer pfSense to the inner pfSense, like there was for other routers in the building. ٩(͡๏̯͡๏)۶
Side note: the "Start DHCP6 client in debug mode" option seen referenced on this forum several places does not seem to exist on either of these routers' WAN interface settings? I thought I'd enabled that before, was that removed? Is there a trick to displaying that?
-
@SteveITS said in Delegate IPv6 subnet to only specific MAC addresses:
Side note: the "Start DHCP6 client in debug mode"
Hidden here :
-
@Gertjan D'oh! I knew I had seen it, thanks.
Unfortunately this was broken twice this morning.
- my static route was no longer in the routing table
- DHCPv6 started handing out IPs again despite being set to allow only known clients.
In limited testing it looks like the problems were:
- DHCPv6 Server does not add a route for delegated prefixes to reserved IPs
- if I restart DHCPv6 Server, my static route is removed from the routing table
- I had to edit and save the route, to get it to work again
I kept banging on it. I set Router Advertisement to Managed so clients couldn't get an IP. However RA is still advertising prefixes to other routers, they are just failing.
At some point I re-saved the office router WAN interface and now that Delegated Prefix shows on the DHCPv6 Leases page. So maybe it was in some weird limbo state from above? I didn't try deleting the static route yet since we're into the workday.
However DHCPv6 Leases still shows leases and prefixes for other routers. Does it just not honor the "Deny Unknown Clients" setting?
Confused about the path forward, do I need to turn off DHCPv6 Server on the building router, and use a static route?
-
...and the route is gone again, don't know why.
Edit: Seems like all the DHCPv6 Server settings are ignored?
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6.html"The DHCPv6 daemon can only run and be configured on interfaces with a Static IP address, so if a tab for an interface is not present, check that it is enabled and set with a Static IP. It is not currently possible to adjust settings for tracked interface DHCP service."
I suppose one could read that as "shouldn't be visible" vs "we'll ignore everything". It does seem to be using the configured address pool though.
-
@SteveITS If you have static IPv6, use it. If it is dynamic then don't. Latter one is not running that well in pfSense. For instance, I get a new prefix every night. I have to reboot my pfsense via cron afterwards to get it working well. But with static IPv6, I don't see that (only have HE).
-
@Bob-Dig I can't really tell without going to the office and testing by booting the Comcast router, which kicks everyone off, but I think Comcast doesn't keep the routes after their router boots. They have a "static IPv6" /56 as they label it but it's handed out to their router automatically by them, and if I configure our pfSenses with all static then there isn't a way for me to configure a static route for the "self-delegated" IPV6, on the Comcast device. It only allows IPv4 routes.
Currently it's working with:
building WAN: DHCP6
building LAN: Track Interface
office WAN: static IPv6
office LAN: static IPv6
building router: needs static route for office LAN
building router: DHCPv6 Server off
building router: RA offI suspect when I was banging on it a month ago the Comcast router kept the route for the delegated prefix, until it booted. So having the building router Track Interface and request a /62 prefix hopefully will keep that route in the Comcast router. Guess I'll find out in the next few months if/when it restarts. And then the fix and that point is probably just to reacquire the building LAN IPv6.
Done automatically I expect it will all work just fine, the problem is we need control over how to hand out addresses.
There's also some sort of a bug I ran into again where if I add an IPv6 gateway on the WAN interface page, it flips the IPv4 gateway to Automatic and disconnects Internet (even though there's only one IPv4 gateway). But that's another story...