Have WAN track WAN IPv6?
-
@mariatech said in Have WAN track WAN IPv6?:
When pfSense originates traffic, it needs to select a source address.
Whatever the source address, it will route appropriately. Also, is pfSense originating that much traffic? Other than a VPN or ssh, etc., I don't see much traffic coming from pfSense compared to something behind it. As for dhcpv6, it's already being used to get your prefix. Also, I don't know that it's advisable to put an address from within your prefix on the WAN side, as that WILL mess up routing, unless you create a specific route for that address.
Someone else has already tried my suggestion for using the LAN interface for a VPN and it worked for them.
-
@jknott
Suppose the following configuration- WAN has link-local address fe80::q:r:s:t
- WAN has obtained a PD 2001:u:v::/48
- LAN tracks WAN, and is assigned 2001:u:v:1::aaaa and fe80::q:r:s:t'
- OPT is statically assigned 2600:w:z::bbbb/127
- the default route ::/0, obtained from the ISP RA is fe80::1 via WAN
Now suppose pfSense has to get something from files.netgate.com [2610:160:11:18::209]. This matches the default route, but since that interface has no global addres, the kernel will pick the longest match from the other interfaces. LAN's address matches the first byte of the destination, OPT matches the first two bytes, hence the source address will be OPTs.
Thus a SYN 2600:w:z::bbbb -> 2610:160:11:18::209 is sent to fe80::1 via WAN. Perhaps this is appropriate, but the ISP only expects to see packets from 2001:u:v::/48, so their ingress filter drops it. Even if fe80::1 were to forward it, the SYNACK would arrive on OPT, asymmetrically. Since pf wouldn't have a state on OPT for that connection, pfSense would drop the SYNACK at that point.
If 2001:u:v:2::cccc/128 were to be assigned to WAN, what would be messed up with the routing? The ISP has the route 2001:u:v::/48 -> fe80::q:r:s:t, everything on LAN has route ::/0 -> fe80::q:r:s:t', and the router on the other end of OPT doesn't need to talk to anything in 2001:u:v::/48 and has static routes to the loopbacks on pfSense. Who would need a specific route to 2001:u:v:2::cccc/128?
-
It appears you're misunderstanding a few things. First, a link local default route is entirely normal and even if you had a global WAN address, it likely wouldn't be used for routing. All a router needs to know is how to get to the next hop. In fact an address isn't even necessary on a point to point link, where all you need is the interface. Second, all routing goes through the internal default route, which is 0.0.0.0/0 on IPv4 and ::/0 on IPv6. PfSense then determines which is the best interface to use. Since an external address does not appear on any interface, traffic for it is sent to your ISP's default route, which is the link local address.
As an experiment, go to the pfSense command line and enter:
ping -S <LAN IP address> google.com and see what happens. Try again with ping6. In this example, the ping is sent out with the LAN interface as the source address, not the WAN interface. It does not matter which interface address you use as a source, so long as it's on your pfSense box. -
$ ping -S 10.d.e.f google.com PING google.com (142.250.217.78) from 10.d.e.f: 56 data bytes 64 bytes from 142.250.217.78: icmp_seq=0 ttl=119 time=18.714 ms ... $ ping6 -S 2001:u:v:1::aaaa google.com PING6(56=40+8+8 bytes) 2001:u:v:1::aaaa --> 2607:f8b0:400a:80a::200e 16 bytes from 2607:f8b0:400a:80a::200e, icmp_seq=0 hlim=119 time=26.177 mshowever,
$ ping6 -S 2600:w:z::bbbb google.com PING6(56=40+8+8 bytes) 2600:w:z::bbbb --> 2607:f8b0:400a:80a::200e ^C --- google.com ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss $ ping6 google.com PING6(56=40+8+8 bytes) 2600:w:z::bbbb --> 2607:f8b0:400a:80a::200e ^C --- google.com ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet lossclearly the source address matters to ping6, and it automatically selects a source that doesn't work.
$ ifconfig cxgbe1.0010 | grep description\\\|inet6 description: WAN inet6 fe80::207:43ff:fexx:xx%cxgbe1.0010 prefixlen 64 scopeid 0x12 $ sudo ifconfig cxgbe1.0010 inet6 2001:u:v:2::cccc/128 $ ifconfig cxgbe1.0010 | grep description\\\|inet6 description: WAN inet6 fe80::207:43ff:fexx:xx%cxgbe1.0010 prefixlen 64 scopeid 0x12 inet6 2001:u:v:2::cccc prefixlen 128 $ ping6 google.com PING6(56=40+8+8 bytes) 2001:u:v:2::cccc --> 2607:f8b0:400a:80a::200e 16 bytes from 2607:f8b0:400a:80a::200e, icmp_seq=0 hlim=119 time=24.928 ms -
Well, I don't know what you're doing wrong as it works here:
ping6 -S 2607:fea8:4c82:5900:4262:31ff:fe12:b66c google.com
PING6(56=40+8+8 bytes) 2607:fea8:4c82:5900:4262:31ff:abcd:1234 --> 2607:f8b0:400b:80c::200e
16 bytes from 2607:f8b0:400b:80c::200e, icmp_seq=0 hlim=117 time=13.908 ms
16 bytes from 2607:f8b0:400b:80c::200e, icmp_seq=1 hlim=117 time=11.672 ms
16 bytes from 2607:f8b0:400b:80c::200e, icmp_seq=2 hlim=117 time=14.432 ms
16 bytes from 2607:f8b0:400b:80c::200e, icmp_seq=3 hlim=117 time=18.986 msIt works with 3 different interfaces, including a VLAN.
cxgbe1.0010 inet6 2001:u:v:2::cccc/128 <--- I'm not sure what you're trying to do here. I have a /128 on my WAN and it works fine. One thing about the /128 is it can never be used for routing, as there is only one possible address, which means there's no "other end" to the connection.
I suspect you have other issues causing this problem, as the -S works fine here for every interface I've tried.
-
@jknott said in Have WAN track WAN IPv6?:
It works with 3 different interfaces, including a VLAN.
Do those interfaces share an ISP assigned prefix? How about
ping6 -S ::1 google.comcxgbe1.0010 inet6 2001:u:v:2::cccc/128 <--- I'm not sure what you're trying to do here.
I'm adding a global address to the WAN interface, as shown by the before and after ifconfig output.
I have a /128 on my WAN and it works fine.
By /128, do you mean global host address? I have shown that when I add a global address from my delegated prefix to the WAN interface, my system works fine too. The problem is that pfSense does not assign said address automatically. How did your WAN get its address?
One thing about the /128 is it can never be used for routing, as there is only one possible address, which means there's no "other end" to the connection.
I'm not sure what you mean by this. Other routers have my loopback /128 addresses as a destination. I do not expect nor want to make a direct connection to any other host in 2001:u:v:2::/64, a prefix of my WAN global address.
-
@mariatech said in Have WAN track WAN IPv6?:
Do those interfaces share an ISP assigned prefix? How about
ping6 -S ::1 google.comYes. They're all part of the /56 I get from my ISP. Only the last 8 bits of the prefix change. For example, the prefix ID for my main LAN is 0, my VLAN, 3. etc. That ::1 is not a valid address for use over the Internet.
By /128, do you mean global host address?
The /128 means the size of the "network" is only 1 device, /127 provides 2, etc. If there is only one device, all that address does is identify the interface. My WAN address is also /128, which means it cannot communicate directly with any other address. As for those other routers, I bet they're using a link local address as happens here.
This is my default gateway from my ISP: fe80::217:10ff:fe9a:a199. The WAN /128 global address is not used for routing. It can be used as a target for VPN etc..
-
Only the last 8 bits of the prefix change. For example, the prefix ID for my main LAN is 0, my VLAN, 3. etc. That ::1 is not a valid address for use over the Internet.
Hence all the source addresses from your ISP-assigned prefix will be acceptable to the ISP's router, and the responses will come back via the same gateway. When your pfSense automatically chooses a source address, it will be one of those, so it will always work. My pfSense has global addresses that do not belong to the default ISP, yet pfSense is selecting those addresses as the source and sending those packets to the ISP via the default gateway. The ISP's router will only forward packets originating from prefixes that the ISP owns, my packets are thus rejected, same as they would reject a packet having ::1 as the source.
My WAN address is also /128
My ISP does not assign any global address (NA), they only offer the PD through DHCP. All I am trying to do is to assign an address from the PD to the WAN, just like I can assign addresses to other interfaces with the 'track interface' option. I have demonstrated that manual configuration solves my source address problem without having to mess with the policy table. There have been no adverse effects wrt routing. The only negative is that if the alias is not removed before soliciting another lease, the interface goes into 'IFDISABLED' state, which has to be cleared before restarting dhcp6c.
-
Why are you trying to use an address that's not provided by the ISP? The Internet routers won't know how to return replies to you. Where are you getting that address from? Since your ISP doesn't provide a WAN address, all you have to do is point to an internal address they do provide, as I have suggested.
-
Why are you trying to use an address that's not provided by the ISP?
Because pfSense is a router
...all you have to do is point to an internal address they do provide, as I have suggested.
The DNS root servers, the package repo, NTP servers, ACME, etc. are internet resources, they are not hosted on my network.
-
The prefix is used to find the network you're connected to. If you use an address from another network any packets that you're expecting will be sent to some other network.
The DNS root servers, etc. have absolutely nothing to do with this. If you take some address that does not belong on your network, the Internet will have no idea that you're using that address and will send all packets to that other network, no exceptions. For example, I'm on Rogers. If you were to use one of my addresses and you tried to do something on the Internet, I'd suddenly start receiving packets that I have no idea about and you'd be sitting there wondering why things don't work. They don't work because they can't work.
You cannot use those addresses while on your ISPs network, with the exception if you have a VPN to the network where that address belongs. In that case, the packets will be sent to that network and then forwarded over the VPN to you. I mentioned my prefixes earlier, where I have a /56 prefix. This provides me with 256 /64 prefixes, where the last 8 bits are used to determine which one. I use the highest one, "ff" for my VPN. So, I could take my notebook computer to some other network and connect to the Internet through my VPN, using an address within that ff network as my source address and everything will work fine. I cannot just take one of those addresses and assign it to my computer while on some other network and expect it to work.
Perhaps you should do some reading on how routing works.
-
Perhaps you should do some reading on how routing works.
Excuse me, everything you have tried to explain in this post can be found in what I have written above.
-
Please explain how you think an address from another network is reachable on yours. You have told me that you are trying to use an address from other than your ISP. How is traffic destined for that address supposed to reach your network?
-
Please explain how you think an address from another network is reachable on yours.
That's not what I think. I haven't said anything that would suggest that.
You have told me that you are trying to use an address from other than your ISP.
A router necessarily has addresses on different networks.
How is traffic destined for that address supposed to reach your network?
Through the peer's ISP.
-
You have a router, with one interface connected to your ISP. You have one or more interfaces for your local LAN. Your router knows about your LAN(s) and your ISPs gateway. That's it, as apparently you don't even get a global WAN address. It knows of no other addresses. The peer (whoever that is) has a similar setup with their ISP (unless they're large enough to have their own autonomous system). If you try to use an address from that other ISP on your router, then you will not see incoming traffic for that address. It will be sent through the other ISP, to that peer, with no way to get to you. This is determined entirely by the network prefixes. The prefix for that peer belongs to that other ISP, not yours.
Here is Google's IPv6 address: 2607:f8b0:400b:80c::200e. Assume they're on an ISP with a /56 prefix like me. The prefix is the first 64 bits, ending in 80c. With a /56, those could be anything between 800 and 8ff. Now, if you were to take an address anywhere within that 2607:f8b0:400b:800/56 and assign it to your firewall, I can guarantee you, you will never, ever see any packets come back to you, because they'd all be sent to Google and not you. What you are trying to do simply won't work, because it violates the way IP networks work. Now, if you had your own autonomous system, where you use a routing protocol, such as BGP, then yes, you could do what you want and then your autonomous network would advertise, via BGP, to the world where to find that address and that would have to propagate around the world for it to work. It would also cause entries in routing tables around the world, to create an exception to where that address would normally go.
What you're trying to do will not work in either IPv4 or IPv6.
-
@jknott said in Have WAN track WAN IPv6?:
You have a router, with one interface connected to your ISP. You have one or more interfaces for your local LAN. Your router knows about your LAN(s) and your ISPs gateway. That's it, as apparently you don't even get a global WAN address. It knows of no other addresses. The peer (whoever that is) has a similar setup with their ISP (unless they're large enough to have their own autonomous system). If you try to use an address from that other ISP on your router, then you will not see incoming traffic for that address. It will be sent through the other ISP, to that peer, with no way to get to you. This is determined entirely by the network prefixes. The prefix for that peer belongs to that other ISP, not yours.
Only until the traffic gets to the peer. They have their own routes pointed at one of their networks, which is connected to one of my interfaces.
Here is Google's IPv6 address: 2607:f8b0:400b:80c::200e. Assume they're on an ISP with a /56 prefix like me. The prefix is the first 64 bits, ending in 80c. With a /56, those could be anything between 800 and 8ff. Now, if you were to take an address anywhere within that 2607:f8b0:400b:800/56 and assign it to your firewall, I can guarantee you, you will never, ever see any packets come back to you, because they'd all be sent to Google and not you. What you are trying to do simply won't work, because it violates the way IP networks work.
That's not what I'm trying to do. Actually that's exactly what is going wrong, at least we are clear on that. But pfSense is doing it anyway.
Now, if you had your own autonomous system, where you use a routing protocol, such as BGP, then yes, you could do what you want and then your autonomous network would advertise, via BGP, to the world where to find that address and that would have to propagate around the world for it to work. It would also cause entries in routing tables around the world, to create an exception to where that address would normally go.
What you're trying to do will not work in either IPv4 or IPv6.The IPv4 WAN interface has a routable address from the ISP. That address is used by the pfSense host as the source address and everything works fine. The default pfSense configuration does not configure the WAN interface with an IPv6 global address. Routing works, but the pfSense host itself cannot communicate on IPv6 for DNS, NTP, ACME, etc. for exactly the reasons you have explained above, because pfSense picks the address from the peer network and tries to use it on my ISP. When I manually configure WAN with one of the addresses from MY ISP, pfSense then uses that address, and everything works fine. But it should not be manually configured, it should be done by DHCP.
Everything you have said above about routing is completely correct and agrees with my previous description of the difficulty. It is not my decision to use an address that is foreign to my ISP. It is pfSense that is trying to do it. I am well aware of the reasons it cannot work.
-
@mariatech said in Have WAN track WAN IPv6?:
My pfSense has global addresses that do not belong to the default ISP, yet pfSense is selecting those addresses as the source and sending those packets to the ISP via the default gateway. The ISP's router will only forward packets originating from prefixes that the ISP owns, my packets are thus rejected
So it boils down to that.
And you can't or don't want to use that other IPv6 connection.
If not assigning an IPv6-address to the WAN is not violating the standards than it is valid to ask for this feature, assigning one prefix to WAN, I guess.
Other than that, maybe you can "hack" something with NPt (or NAT) and virtual IPs on WAN.
-
If I'm hacking anything I'll probably try to hook into DHCP and automatically assign an alias as detailed above. Then I would have to verify the behaviour when the link flaps or disconnects.
I don't know what the rationale was here
RFC3633 (Obsolete)
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.but the prohibition is implicitly downgraded
RFC 6603 (Updates: 3633)
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(67), that is used to exclude exactly one prefix from a delegated
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE
option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a
prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
/64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set.]No mention of OPTION_PD_EXCLUDE (67) in dhcp6c.conf(5), though it is in dhcpcd.conf(5). I have yet to try this option.
The existing CPE assigns a /64 prefix to the LAN and reports having a global WAN address belonging to the successively numbered /64. I'm not set up at the moment to capture traffic on the ISP side of the CPE.
-
@mariatech I'd be curious if you find a way to script this or something to make this work and be automated. Please share the knowledge if you do! My ISP (Verizon) uses RFC6603 and gives out a /56 and assigns the isp cpe the FF prefix. Sure, everyone says to just manually assign a virtual IP, but those random PD changes will get ya. Or to use a lan ipv6 address. It's disappointing that crappy ISP provided routers/equipment supports RFC6603 but something that is miles and miles more advanced like pfSense doesn't (yet?) If dynamic ip address updaters allowed you to use the lan ipv6 address to update a dynamic dns that would be a help too, but alas they don't...
-
@mariatech Just for completeness, what happens if you don't have another public IPv6-connection from somewhere else on pfSense? Probably pfSense would only use IPv4 for its own needs with no interruptions/problems.
