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>
    [...]


  • LAYER 8 Netgate

    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.


  • LAYER 8 Netgate

    All of the necessary prefix information is right there in the interface status already shared.



  • @Derelict

    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 loss

    Source 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 ms

    Source 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 loss

    Source 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 loss

    Source 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 loss

    Pinging fe80::2ab4:48ff:fe87:c9fb%igb0:
    WAN: Unsuccessful
    LAN: successful
    WAN IPV6 Link-local: successful
    WAN IPV6 Link-local: Unsuccessful

    Thanks.
    Andrew.


  • LAYER 8 Netgate

    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 loss

    That 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.


  • LAYER 8 Netgate

    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.


Log in to reply