ipv6 client routing issue



  • I have an issue where ipv6 routing works great if I test on the pfsense box. I can ping google.com from the lan or the wan. If I try the same thing from the client if fails. packet captures on pfsense show my requests never make it to the wan interface from the client machine. I know its a routing problem but I cant figure it out.

    I have a /56 that is given to me by my ISP. that /56 is routed to my Cisco 1921 router. My pfsense is connected directly to the 1921.

    pfsense static WAN address

    2001:XXXX:XXXX:100::12/64
    

    pfsense wan upstream gateway

    2001:XXXX:XXXX:100::1
    

    pfsense LAN static address

    2001:XXXX:XXXX:112::1/64
    

    static route on my 1921 (so traffic can get to the internet)

    ipv6 route ::/0 2001:XXXX:XXXX:80:: (ISP next hop)
    

    static route on my 1921 (so traffic can get back to pfsense)

    ipv6 route 2001:XXXX:XXXX:112::/64 2001:XXXX:XXXX:100::12 (entire /64 assigned to pfsense routed to pfsense WAN address)
    

    I run a test lab from my home office and I have a Cisco ASA and PA firewall configured as above and they work fine.
    On pfsense I have DHCPv6 configured on the lan interface as well as RA (tried every combo of RA). The client gets one or more v6 addresses no problem. The issue is that I cannot get any traffic to route from the client.

    I can however ping or tracert from the pfsense box from the LAN v6 ip to any v6 resource on the internet and that works fine. that tells me that my 1921 static routes are OK.

    PING6(56=40+8+8 bytes) 2001:XXXX:XXXX:112::1 --> 2607:f8b0:4004:811::200e
    16 bytes from 2607:f8b0:4004:811::200e, icmp_seq=0 hlim=54 time=8.622 ms
    16 bytes from 2607:f8b0:4004:811::200e, icmp_seq=1 hlim=54 time=8.673 ms
    16 bytes from 2607:f8b0:4004:811::200e, icmp_seq=2 hlim=54 time=8.816 ms
    
    1  2001:XXXX:XXXX:100::1  0.591 ms  0.452 ms  0.423 ms
     2  2001:XXXX:XXXX:80::  3.344 ms  3.277 ms  3.308 ms
     3  2001:578:2401:0:1:9000:0:3  3.737 ms  3.287 ms  3.267 ms
     4  2001:578:2401:0:1:8000:0:11a  3.081 ms  3.264 ms  3.111 ms
     5  2001:578:1:0:172:17:249:49  8.532 ms  8.697 ms  8.608 ms
     6  2001:578:20:2100::e:1  9.133 ms
        2001:578:20:2000::12:1  8.627 ms
        2001:578:20:2100::e:1  9.121 ms
     7  2001:4860:0:1::24a4  8.954 ms
        2001:4860:0:eaf::1  9.114 ms
        2001:4860:0:1::24a4  8.861 ms
     8  2001:4860:0:1::1b75  9.772 ms  9.385 ms  9.529 ms
     9  2607:f8b0:4004:811::200e  8.711 ms  8.619 ms  8.786 ms
    

    I know it has to be routing, what am I missing?



  • Also should add that I cannot ping the pfsense ipv6 lan gateway from the client either



  • Do the clients have an IPv6 address within the same prefix as pfSense?

    BTW, why are you using both pfSense and a Cisco router?



  • @jknott
    yeah here is an example:

    2001:XXXX:XXXX:112:2977:9c75:ee13:57b4
    

    My fiber ISP terminates on my Cisco 1921 router. Then hanging off of that I have a PA firewall, Cisco ASA, and pfsense. There is no routing between the Cisco, PA, and pfsense box. My 1921 basically is an internet facing router.



  • @jknott
    You can think of my 1921 as the ISP. Basically there is 1 address in a /64 for the wan and another /64 entire subnet for the LAN. Static routes on the 1921 route the lan /64 range to the single /64 wan address



  • Normally, an ISP uses DHCPv6-PD to assign a prefix to a customer. Mine gives me a /56, which is 256 /64s. PfSense then assigns individual /64s to interfaces and VLANs. Now, with that Cisco router, it may be able to assign a /64 to LAN connection containing pfSense, but I doubt there'd be any method for pfSense to pass anything off to the local LAN. Are both sides of pfSense on the same prefix, by any chance?



  • @jknott Yeah I own the entire /56. Cox Business gives me a /127 or something as my v6 address. then they give me a /56 that is statically routed to that single address.
    then my 1921 has a static address in the /56 and static routes multiple /64's to different destinations (PA, ASA etc)

    so both sides of the pfsense box have separate /64's but are both contained in the /56 that the ISP routes to me



  • The part that I cannot understand is that LAN > WAN v6 routing is working fine from pfsense. I can resolve and ping any v6 internet address. Its just from the client. It feels like the clients do not know how to get to their next hop even though I am using dhcp and RA.



  • Time to fire up Wireshark.

    There should be router advertisements, which not only specify the prefix but also the router address. Do you see that?



  • It looks like it is doing RA's but I dont know enough about v6 to tell if they are correct?

    21:56:53.828588 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d.57000 > 2001:4860:4860::8888.53: UDP, length 33
    21:56:56.499143 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2607:f8b0:4004:80a::200e: ICMP6, echo request, seq 21, length 40
    21:56:58.605293 IP6 fe80::c15a:26d2:6260:3001 > fe80::250:56ff:fe9c:8801: ICMP6, neighbor solicitation, who has fe80::250:56ff:fe9c:8801, length 32
    21:56:58.605354 IP6 fe80::250:56ff:fe9c:8801 > fe80::c15a:26d2:6260:3001: ICMP6, neighbor advertisement, tgt is fe80::250:56ff:fe9c:8801, length 24
    21:57:01.150246 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2607:f8b0:4004:80a::200e: ICMP6, echo request, seq 22, length 40
    21:57:02.548979 IP6 fe80::250:56ff:fe9c:8801 > ff02::1: ICMP6, router advertisement, length 152
    21:57:02.744943 IP6 fe80::250:56ff:fe9c:8801 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
    21:57:03.848072 IP6 fe80::250:56ff:fe9c:8801 > fe80::c15a:26d2:6260:3001: ICMP6, neighbor solicitation, who has fe80::c15a:26d2:6260:3001, length 32
    21:57:03.848523 IP6 fe80::c15a:26d2:6260:3001 > fe80::250:56ff:fe9c:8801: ICMP6, neighbor advertisement, tgt is fe80::c15a:26d2:6260:3001, length 32
    21:57:04.547957 IP6 fe80::250:56ff:fe9c:8801 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
    21:57:05.505313 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2001:4998:58:1836::10: ICMP6, echo request, seq 23, length 40
    21:57:06.128300 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2607:f8b0:4004:80a::200e: ICMP6, echo request, seq 24, length 40
    21:57:10.132181 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2001:4998:58:1836::10: ICMP6, echo request, seq 25, length 40
    21:57:11.121105 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2607:f8b0:4004:80a::200e: ICMP6, echo request, seq 26, length 40
    21:57:15.143964 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2001:4998:58:1836::10: ICMP6, echo request, seq 27, length 40
    21:57:20.149722 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d > 2001:4998:58:1836::10: ICMP6, echo request, seq 28, length 40
    21:57:22.178316 IP6 fe80::250:56ff:fe9c:8801 > ff02::1: ICMP6, router advertisement, length 152
    21:57:23.873947 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d.59440 > 2001:4860:4860::8888.53: UDP, length 46
    21:57:23.874302 IP6 2001:57a:2200:112:444:4bf7:c0e4:333d.59682 > 2001:4860:4860::8888.53: UDP, length 46



  • never though I would ever say this but a reboot fixed the issue. Feeling pretty stupid now.... Pfsense should prompt in my opinion if it needs it but nevertheless I should have thought about it myself.

    Thanks for the time :-)



  • @slampman said in ipv6 client routing issue:

    It looks like it is doing RA's but I dont know enough about v6 to tell if they are correct?

    That looks like Packet Capture. I much prefer Wireshark, as it provides much more info. However, you can download the capture and open the file with Wireshark.

    There is a router advertisement there:
    21:57:02.548979 IP6 fe80::250:56ff:fe9c:8801 > ff02::1: ICMP6, router advertisement, length 152

    But since I can't see it in Wireshark, I can't tell you much about it, other than the router link local address and it's an unsolicited multicast, rather than a response to a request. If I could view it in Wireshark, I'd be able to determine the prefix used for the network and some other things.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy