IPv6 with Gateway on a different network
-
pfSense version: 2.3.3.a.20161015.0942
My provider has a bizarre setup where the gateway is not on the same network as the public address range that is assigned. I agree this goes against every networking principle, and has caused me pain on a number of occasions. I have to keep this server with them for reasons though. IPv4 works just fine with the crazy gateway, but IPv6 does not.
I have "use non-local gateway" checked under System/Routing/Gateways. And the proper gateway is assigned to the WAN interface IPv6 address. I also added a few virtual IPv6 addresses under Firewall/Virtual IPs for good measure.
Output of netstat -rn6 is attached.
From the output it looks like the IPv6 addresses I added, including the address for the WAN interface (:108) are only pointing to loopback and not also to em0. I can ping the gateway from the outside, as well as from other vm boxes on the host that are not behind pfSense.
Any suggestions?
ip6_routes.txt -
My provider has a bizarre setup where the gateway is not on the same network as the public address range that is assigned.
That's entirely normal. With IPv6, the link-local address of the router is typically used. On my network, both the local gateway and the WAN gateway are link-local addresses. Even with IPv4, it was possible to do similar, by specifying the gateway interface, rather than IP address.
Are they providing a link-local or global unicast address for the gateway?
-
That's a good question. The site ID portion is 6236 (X:X:X:6236::/64) and the gateway is 62FF (X:X:X:62FF:ff:ff:ff:ff). From what I've read on IPv6 I think that means its global unicast, but I've only recently delved into IPv6. The server provider is OVH if that clarifies things. I just though it odd that the WAN IPv6 address, and even the test virtual IPs I entered, don't point to the outward facing network interface in the routing table like with IPv4. They just point to the loopback interface.
-
You should receive the gateway via a router advertisement and should not need to do anything special.
It is not uncommon (even expected) for the gateway to be a link-local address.
Cox gives me this: Gateway IPv6 fe80::e6d3:f1ff:fe80:f0d9
IPv6 is completely different from IPv4 in this area.
-
From what I've read on IPv6 I think that means its global unicast, but I've only recently delved into IPv6.
At the moment, global unicast addresses start with 2 or 3. However, at some time in the future, the range of GUAs may be increased. Presently over 3/4 of the IPv6 address space is not allocated for anything, so there's plenty of room for expanding the GUA space.
BTW, I good reference is IPv6 Essentials http://shop.oreilly.com/product/0636920023432.do
They just point to the loopback interface.
That's the way all routers work. A packet is forwarded to the loop back and then the routing software takes it from there to the appropriate interface. You don't often see that in home routers, but you certainly do in business grade routers from Cisco etc..
IPv6 is completely different from IPv4 in this area.
Actually, use of the link-local address is the only way IPv6 routing differs from IPv4. While the link-local address is commonly used, you can also use a globally unique or unique local address or the interface, just as you can in IPv4.
-
Unfortunately GUA apparently isn't an option on OVH per their IPv6 docs. They even recommend turning off router advertisements. Manually specifying the IPv6 gateway works flawlessly on all my other *nix boxes, and as much as I hate to say it Windows gets top marks for ease of setup in this area.
I would expect the IP to go to loopback, but I'd also expect that the address be associated with an interface. In routes.txt I've less obfuscated the addresses and included the IPv4 portion. As you can see the outside addresses in IPv4 are going to lo0, but the ip is also associated with the WAN interface em0. In the IPv6 portion, the only addresses associated with em0 are OpenDNS servers. :109, :112, :113 are virtual IPs I've added, with :118 being the WAN IP - none of which are bound to anything other than Lo0.
You can see in the route2_Centos7.txt file the IPv6 routing table from a working multi IP Centos box on the same VM host. Each IPv6 is associated with both lo and eno16777984 (WAN interface).
-
As mentioned earlier, the link-local address is normally used, not a GUA. The link-local destination is learned from the router advertisement and the router learns which interface it came on in. Are you not receiving router advertisements?
-
No. OVH even specifically tells you to turn that off in the doc I linked. I fail to see how router advertisements would prevent the IPs from being associated with the outbound interface, when manually specifying the gateway works in every other linux vm on the same ESXi box with multiple outside IPs pass traffic. You can see this quite clearly from the Centos IPv6 routing table. It is also present in the routing table from the pfSense box clearly showing an IPv4 /24 binding IPs the the internal interface. The Centos box does the same, but with a /128. Otherwise how would the box know to listen for traffic without something linking an address space to the external interface?
From Centos:
2607:xxxx:xx:6236::101/128 :: U eno16777984
2607:xxxx:xx:6236::101/128 :: Un loFrom IPv4 on the firewall:
158.x.x.144 link#1 UHS lo0
158.x.x.144/32 link#1 U em0From IPv6 on the firewall:
2607:xxxx:xx:6236::109 link#1 UHS lo0I would also expect to see, bit don't:
2607:xxxx:xx:6236::109/128 link#1 U em0I probably should have titled this differently in hindsight. The gateway looks correctly set in the routing table:
default 2607:xxxx:xx:62ff:ff:ff:ff:ff UGS em0
2607:xxxx:xx:62ff:ff:ff:ff:ff 00:ff:ee:dd:cc:bb UHS em0 -
Here are the first few lines of my routing table:
Internet6:
Destination Gateway Flags Netif Expire
default fe80::217:10ff:fe91:41f%re0 UGS re0
::1 link#6 UH lo0
2001:4860:4860::8844 fe80::217:10ff:fe91:41f UGHS re0
2001:4860:4860::8888 fe80::217:10ff:fe91:41f UGHS re0And yours
Internet6:
Destination Gateway Flags Netif Expire
default xxxx:xxxx:xx:62ff:ff:ff:ff:ff UGS em0
::1 link#6 UH lo0
xxxx:xxxx:xx:6236::109 link#1 UHS lo0
xxxx:xxxx:xx:6236::112 link#1 UHS lo0One thing I noticed on yours is the default doesn't list %interface. Is that correct? Or did you just omit it when hiding your addresses? That is essential with link-local addresses BTW, you don't need to hide the ISPs portion of the address.
What type of connection are you using? I'm on a cable modem. I can understand them using a non network address, so long as the interface connects to the gateway and it's a point to point link. You'll certainly have a point to point link with ADSL and I believe cable modem, though not sure. It won't work on a broadcast type connection, as you'd normally have on an Ethernet network. Do you have any way to monitor the traffic? There is "Packet Capture" in pfSense, but I prefer Wireshark.
-
I rent a server from OVH. This is not on any type of home connection, but a server in a datacenter. My gateway is different because it specifies the MAC and interface that the DG routes to since the DG is not on a local network. It also looks like IPv6 DNS is working, probably because the OpenDNS IPV6 addresses specify em0 in the route table:
/root: ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2607:5300:60:6236::118 –> 2607:f8b0:4006:809::200e
^C
--- ipv6.l.google.com ping6 statistics ---
105 packets transmitted, 0 packets received, 100.0% packet loss -
I don't know what good a /64 designed to be used on a server (like a web server, plesk, cpanel, etc) is going to do for you on pfSense. You will have IPv6 addresses for your WAN but not much else. You really need a routed /48 for assignment of /64s to interfaces behind the firewall.
The AAAA record for www.google.com was probably returned by an IPv4 name server.
root: drill @4.2.2.2 www.google.com aaaa
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 12014
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.google.com. IN AAAA;; ANSWER SECTION:
www.google.com. 165 IN AAAA 2404:6800:4005:80b::2004 -
OK. Lets just ignore all the internal vs external routing for a minute and focus on one problem for right now, since things are getting muddied up in a general (although informative) IPv6 routing discussion. My core issue is IPv6 doesn't work on the WAN interface.
I cant ping6 the external IPv6 address assigned to pfSense (with proper FW rules in place to allow) WAN interface when the gateway is not on the same network. I also can't ping6 from the box to ipv6.google.com in shell or web interface. I do have use non-local gateway checked on the gateway config. Please help me solve this issue, since this at the very least should work but doesn't.
