IPv6 WAN configuration for static IP address range but gateway from RA message?
-
@virgiliomi Okay, assigning separate /64 subnets was always the plan, but that's where I run into trouble.
Right now, my WAN has the static address aaaa:bbbb:100::/48. Trying to assign the aaaa:bbbb:100:1::/64 static address to one of the VLANs, I get an error message:
IPv6 address aaaa:bbbb:100:1::/64 is being used by or overlaps with: WAN (aaaa:bbbb:100::/48)
If the idea is to instead use RA to broadcast that as the subnet - okay, fair enough, but then what do I put as the static address for the VLAN?
@Derelict Okay, but I don't see a way to configure static to obtain the gateway from RA, just to pick a statically entered gateway.
-
@jespertreetop Again, hard to say without seeing exactly what they are sending. Have you tried just not setting a gateway on WAN and seeing what shows up via RA?
Or setting it to SLAAC is also an option.
-
@jespertreetop said in IPv6 WAN configuration for static IP address range but gateway from RA message?:
Right now, my WAN has the static address aaaa:bbbb:100::/48
Never put a /48 on an interface. That is almost always wrong. /64. Always /64 unless it is a statically-configured point-to-point link or similar and they tell you to use something like /126.
-
@derelict Okay, that penny dropped and that makes sense - but I'm in the mindset that WAN and the uplink are synonymous and that all traffic enters through the WAN and have never had public addresses on other interfaces before. Doesn't that mean that the traffic to the VLAN ranges won't know to get there from WAN? Or does all this magically work its way out as long as everything is correct in the routing table, and the traffic from the outside will definitely reach everything with a public address no matter what? WAN has an upstream gateway and the others don't, after all.
-
@jespertreetop It's all routing.
Your LAN clients send their traffic to the pfSense LAN interface because they have received an RA from it and set their default gateway accordingly.
Your pfSense firewall looks at the destination and sends it to its default gateway that was configured however it was configured (RA or static).
The only time an address must exist on an interface is if the firewall must respond to Neighbor Discovery. The only neighbor that the ISP needs to discover is the address the /48 is routed to. Everything else (the /48) is just routed to that neighbor address.
The only real difference between IPv6 routing and IPv4 routing at this basic level is the introduction of the Router Advertisement.
-
@derelict Well, bloody hell, I have a lot to think about. I've been to school for this stuff (Please Do Not Throw Sausage Pizza Away) but it pre-dated widespread IPv6 deployment and not all of it has been exercised regularly. Thanks for your patience and clarity - there are many guides about how to split up and manage and plan out /48 nets into /64 nets and so on, but I guess it's never really spelled out in explicit detail that you shouldn't do what I did and only deal in concrete /64 nets at this layer. (For what it's worth, the pfSense documentation could stand to gain a lot from a "so you have a functioning IPv4 gateway and you're tasked with adding IPv6 connectivity" page with a checklist of what to think about and what maps cleanly to things and what doesn't.)
@virgiliomi Thanks to you too, I think Derelict took over at some point.
-
@derelict So just to bring all this together, since I'm having some trouble getting this to work but don't quite know if it's mismatching the IP address from the RA, but also have to stop now and get back to this tomorrow:
Currently, in IPv4 land, we have a x.y.z.50/28 net on the WAN interface. Using NAT, we map x.y.z.54 traffic on port 443 to 10.1.41.123, to get the https traffic from that public IP to the server in one of the VLANs, the 41 VLAN (which has the net 10.1.41.1/24).
In IPv6 land, we could instead have aaaa:bbbb:100:1::/64 on the WAN interface (and a gateway set for it). We could also have, on the 41 VLAN, the address range aaaa:bbbb:100:41::1/64 without a gateway set, and the same server, if it had the statically assigned address aaaa:bbbb:100:41::123, could then receive https traffic from the public via its own IP (aaaa:bbbb:100:41::123), assuming the rules allowed this. As long as that server has the aaaa:bbbb:100:41::1 address as its IPv6 default gateway, the traffic to its own IP address will arrive to it, and the traffic sent from it will come from that IP address.
Is this correct?
-
In IPv6 land, we could instead have aaaa:bbbb:100:1::/64 on the WAN interface (and a gateway set for it).
@jespertreetop Sounds about right. But the WAN configuration depends on how the ISP is actually provisioned. If they are not provisioned to receive traffic on the gateway address in aaaa:bbbb:100:1::/64 it won't work because you'll do a Neighbor Discovery for it and there will be no answer.
-
@jespertreetop said in IPv6 WAN configuration for static IP address range but gateway from RA message?:
but I'm in the mindset that WAN and the uplink are synonymous and that all traffic enters through the WAN and have never had public addresses on other interfaces before.
This is one area where IPv4 & IPv6 differ. You may have a public WAN address or you might not. You often don't need one, as the link local address can be used for routing. Also, if you do have one, the public WAN address is rarely within your prefix. With IPv6 global addresses, they are all "public".
-
@jknott But in this case the ISP would need a mechanism to discover the correct link-local address to route the /48 to. There is no defined method for doing that.
-
That would depend on the connection method. With DHCPv6-DP, that's part of the process. There was also another thread recently, where the ISP assigned a link local address to be used.
-
@jknott This particular user does not have DHCP6. Nor have they stated that they were assigned anything specific to use on WAN.
-
Part of the problem is we have no idea what that ISP is doing (and maybe they don't either).
-
There's been a lot of small events here, but something happened that was so confounding as to make me think it was worth asking here.
Our ISP has set up a DHCPv6 server now, and when they attach a virtual machine running pfSense to the same subnet as us, everything works fine for them. But when we try to use DCHPv6 from our pfSense, it doesn't. Turning on client logging in both places, their log sees an RA message and ours doesn't.
Here's their log:
Mar 24 15:03:03 dhcp6c 46241 Sending Solicit
Mar 24 15:03:03 dhcp6c 46241 set client ID (len 14)
Mar 24 15:03:03 dhcp6c 46241 set identity association
Mar 24 15:03:03 dhcp6c 46241 set elapsed time (len 2)
Mar 24 15:03:03 dhcp6c 46241 set option request (len 4)
Mar 24 15:03:03 dhcp6c 46241 send solicit to ff02::1:2%vtnet0
Mar 24 15:03:03 dhcp6c 46241 reset a timer on vtnet0, state=SOLICIT, timeo=15, retrans=118860
Mar 24 15:03:03 dhcp6c 46241 receive advertise from fe80::xxxx:xxxx:xxxx:2e00%vtnet0 on vtnet0
Mar 24 15:03:03 dhcp6c 46241 get DHCP option identity association, len 60
Mar 24 15:03:03 dhcp6c 46241 IA_NA: ID=0, T1=0, T2=0
Mar 24 15:03:03 dhcp6c 46241 get DHCP option status code, len 44
Mar 24 15:03:03 dhcp6c 46241 status code: no addresses
Mar 24 15:03:03 dhcp6c 46241 get DHCP option client ID, len 14
Mar 24 15:03:03 dhcp6c 46241 DUID: 00:01:00:01:27:ed:xx:xx:xx:xx:xx:xx:xx:xx
Mar 24 15:03:03 dhcp6c 46241 get DHCP option server ID, len 14
Mar 24 15:03:03 dhcp6c 46241 DUID: 00:01:00:01:26:ad:xx:xx:xx:xx:xx:xx:xx:xx
Mar 24 15:03:03 dhcp6c 46241 get DHCP option DNS, len 32
Mar 24 15:03:03 dhcp6c 46241 get DHCP option domain search list, len 19
Mar 24 15:03:03 dhcp6c 46241 server ID: 00:01:00:01:26:ad:xx:xx:xx:xx:xx:xx:xx:xx, pref=-1
Mar 24 15:03:03 dhcp6c 46241 advertise contains no address/prefixAnd here's ours:
Mar 24 16:24:49 dhcp6c 68621 Sending Solicit
Mar 24 16:24:49 dhcp6c 68621 a new XID (561ccc) is generated
Mar 24 16:24:49 dhcp6c 68621 set client ID (len 14)
Mar 24 16:24:49 dhcp6c 68621 set elapsed time (len 2)
Mar 24 16:24:49 dhcp6c 68621 send solicit to ff02::1:2%igb0
Mar 24 16:24:49 dhcp6c 68621 reset a timer on igb0, state=SOLICIT, timeo=0, retrans=1006
Mar 24 16:24:50 dhcp6c 68621 Sending Solicit
Mar 24 16:24:50 dhcp6c 68621 set client ID (len 14)
Mar 24 16:24:50 dhcp6c 68621 set elapsed time (len 2)
Mar 24 16:24:50 dhcp6c 68621 send solicit to ff02::1:2%igb0
Mar 24 16:24:50 dhcp6c 68621 reset a timer on igb0, state=SOLICIT, timeo=1, retrans=2004
Mar 24 16:24:52 dhcp6c 68621 Sending SolicitBut here's the really strange thing. Doing a packet capture on our pfSense (only ICMPv6, only on the WAN interface), we see that a router advertisement message is being sent, the same type as warrants a "receive advertise" line in their log. Adding a firewall rule to WAN which allows all ICMPv6 and logs it does not result in any logs nor any built-up state.
Are there any good leads as to what could cause this?
-
@jespertreetop Where do you see RAs there?
RAs really have nothing to do with DHCP6. Unlike IPv4 the addressing from DHCP6 and acquiring the router/gateway settings are two distinct processes.
-
@derelict Of course, it was one of the DHCPv6 messages. That makes a lot of sense. (I thought this was RA-related since as discussed before, the DHCPv6 mode is the only way aside from SLAAC to make pfSense pick the gateway from the RA message.) So we're back to not receiving the DHCPv6 messages at all. I added similar rules for DHCPv6 messages, and we just don't see them at all. But that's not an issue for this thread.
