IPV6 working on LAN but not pfSense box itself
-
Hi all,
I have a pretty stock default pfSense installation connecting to an ISP providing Ethernet service giving me IPV4 and IPV6 connectivity. This just worked out of the box, except for any communication on the pfSense box going over IPV6 is not getting through. This manifests in a bogons update error each day. I have fixed this by changing the option in the advanced settings to use IPV4 for outgoing connections but would like to troubleshoot this if possible. LAN clients using IPV6 seems to be ok.
Here is the interface status, one thing I noticed is my IPV6 block from the ISP is /56 but either pfSense or the ISP DHCP has handed out a /64 subnet.
Any suggestions?
Thanks.
Andrew.WAN Interface (wan, igb0)
Status: up
DHCP: up
MAC Address: 00:1a:8c:4b:36:6c
IPv4 Address: 88.98.222.211
Subnet mask IPv4: 255.255.255.248
Gateway IPv4: 88.98.222.209
IPv6 Link Local: fe80::21a:8cff:fe4b:366c%igb0
IPv6 Address: 2a01:4b00:367b:5801:641a:32ef:9a9f:817a
Subnet mask IPv6: 128
Gateway IPv6: fe80::2ab4:48ff:fe87:c9fb
DNS servers: 127.0.0.1, 188.172.144.120, 141.0.144.64
MTU: 1500
Media: 1000baseT <full-duplex>
[...]LAN Interface (lan, igb1)
Status: up
MAC Address: 00:1a:8c:4b:36:6d
IPv4 Address: 192.168.1.1
Subnet mask IPv4: 255.255.255.0
IPv6 Link Local: fe80::1:1%igb1
IPv6 Address: 2a01:4b00:8686:a900:21a:8cff:fe4b:366d
Subnet mask IPv6: 64
MTU: 1500
Media: 1000baseT <full-duplex>
[...] -
All interfaces get a /64. That is the interface prefix size. The /56 from the ISP is enough for 256 /64 interfaces. 2a01:4b00:8686:a900::/64 through 2a01:4b00:8686:a9ff::/64
All of that looks good. From the command line can you do this?
ping6 fe80::2ab4:48ff:fe87:c9fb%igb0??Do you get an IPv6 answer for
dig www.google.com aaaa??Can you
ping6 www.google.com?? -
@adhodgson said in IPV6 working on LAN but not pfSense box itself:
Here is the interface status, one thing I noticed is my IPV6 block from the ISP is /56 but either pfSense or the ISP DHCP has handed out a /64 subnet.
It is pfSense that creates the /64 prefix on your LAN. It takes one of the /64s from your /56 and assigns it to the LAN. You can choose which one. On the WAN side, you might not see a /64, other than for the link local address. The WAN address is often just a /128. This is because, with IPv6, the link local address is used for routing, not the WAN address. Since you haven't shown any prefixes, we can't tell what you have.
-
All of the necessary prefix information is right there in the interface status already shared.
-
My mistake. I guess I better have another beer.
To the OP, the usual way to denote the prefix or subnet mask is with a / as in /64, etc..
-
Hi,
The only info the ISP gave me for the full prefix is 2a01:4b00:8686:a900::/56 and my thinking was correct that pfSense was handing out a /64, I think the client stuff is all working fine from the LAN, its just the routing on the box itself that is broken.
I get IPV6 answers back from the nameserver fine.
Here is the result of pinging www.google.com from the interface:
Source address: WAN
PING6(56=40+8+8 bytes) 2a01:4b00:367b:5801:641a:32ef:9a9f:817a --> 2a00:1450:4009:81a::2004--- www.google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossSource address: LAN
PING6(56=40+8+8 bytes) 2a01:4b00:8686:a900:21a:8cff:fe4b:366d --> 2a00:1450:4009:81a::2004
16 bytes from 2a00:1450:4009:81a::2004, icmp_seq=0 hlim=248 time=1.499 ms
16 bytes from 2a00:1450:4009:81a::2004, icmp_seq=1 hlim=248 time=1.354 ms
16 bytes from 2a00:1450:4009:81a::2004, icmp_seq=2 hlim=248 time=1.348 msSource address: WAN IPV6 Link-Local
PING6(56=40+8+8 bytes) fe80::21a:8cff:fe4b:366c%igb0 --> 2a00:1450:4009:81a::2004--- www.google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossSource address: LAN IPV6 Link-Local
PING6(56=40+8+8 bytes) fe80::1:1%igb1 --> 2a00:1450:4009:81a::2004
ping6: wrote www.google.com 16 chars, ret=-1
ping6: wrote www.google.com 16 chars, ret=-1
ping6: wrote www.google.com 16 chars, ret=-1--- www.google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossSource address: localhost
PING6(56=40+8+8 bytes) ::1 --> 2a00:1450:4009:81a::2004
ping6: wrote www.google.com 16 chars, ret=-1
ping6: wrote www.google.com 16 chars, ret=-1
ping6: wrote www.google.com 16 chars, ret=-1--- www.google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossPinging fe80::2ab4:48ff:fe87:c9fb%igb0:
WAN: Unsuccessful
LAN: successful
WAN IPV6 Link-local: successful
WAN IPV6 Link-local: UnsuccessfulThanks.
Andrew. -
Well you are never going to get any network address translation so sourcing from a link-local address will only allow you to access things on that prefix/subnet.
Here is the result of pinging www.google.com from the interface:
Source address: WAN
PING6(56=40+8+8 bytes) 2a01:4b00:367b:5801:641a:32ef:9a9f:817a --> 2a00:1450:4009:81a::2004
--- www.google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossThat should work. I would packet capture on WAN for that traffic and if it is going out there should be a response. If there is not there is nothing pfSense can do about it. You should be able to see the MAC address of the default IPv6 gateway at fe80::2ab4:48ff:fe87:c9fb. The outgoing packets should be being sent to that MAC address. You will need to look in the NDP table, not the ARP table because IPv6.
If you were to packet capture on WAN for anything to address 2a01:4b00:367b:5801:641a:32ef:9a9f:817a then ping6 it from the outside, I'll bet you don't even see the traffic arrive, which it absolutely should.
It's like they are routing the /56 to you but not the interface address, which is weird.
-
Hi,
Thanks for this it is very helpful. As you have explained I did a packet capture and can see the traffic going out to the default gateway from the WAN address but cannot see the response. I also tried pinging an internal IPV6 host which works fine but whatever I do I can't get the WAN address to respond to pings so something is broken. Have you seen anything like this before, is it a common ISP issue? Could I potentially use one of the /64s on the WAN side? The ISP are unable to help in this situation as its not their kit. I wouldn't mind so much but I don't think I can check it on their kit either as there is no way to view the WAN address.
Thanks.
Andrew. -
It does not matter what "kit" you are using. Packet captures don't lie. Press them. If they are assigning you a WAN address and they are not passing traffic to/from that address it is their problem to fix, not yours, not ours. I would not call it a typical problem. When an ISP assigns you a routable (GUA) address on WAN it is usually, you know, routable.
The organic address to use for outgoing connections from the firewall is the WAN GUA address. There are certain things in which you can control what source address is used but many you cannot. You could certainly make a localhost IP Alias VIP for something like
2a01:4b00:8686:a9ff::1(The all-ones /64 from the /56) and tell what you can to source from that. That should work where that option is available. But you could also just use LAN address. -
@adhodgson said in IPV6 working on LAN but not pfSense box itself:
Could I potentially use one of the /64s on the WAN side?
No point in doing that. You already have a /128 address on the WAN and the link local address is used for routing. That's all you need.
I had a problem with my ISP a few months ago. I used Wireshark and Packet Capture to see what was happening. I also tethered my notebook computer to my cell phone so that I could test from outside my network. With that, I was able to determine that the problem was not on my network and was even able to identify, by host name, the failing system at my ISP.
One thing I did, which helped is I used a 5 port switch, configured as a data tap, to monitor the traffic between my modem and firewall, when pfSense was booting up.
