IPv6 WAN configuration for static IP address range but gateway from RA message?
-
@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.
