IPv6 working but I have to disable gateway monitoring



  • I'm getting an address range (ISP=Spectrum/TW) but I have to disable monitoring as it doesn't seem able to determine the upstream gateway IPv6 address to monitor.

    Any suggestions?


  • LAYER 8

    i don't know about your isp but
    you can use 2001:4860:4860::8888 as monitor ip for example



  • @kiokoman Thanks. I was doing that manually, but I would have hoped that the DHCP6 would provide a proper upstream gateway IPv6 address for the pfsense client to then use.



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    @kiokoman Thanks. I was doing that manually, but I would have hoped that the DHCP6 would provide a proper upstream gateway IPv6 address for the pfsense client to then use.

    What gateway address are you getting? It's entirely normal for link local addresses to be used for the gateway.



  • @JKnott I am getting a link local address for the IPv6 gateway. Why can't the DHCP6 client then use that for monitoring? If I manually add it, it doesn't work.



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    @JKnott I am getting a ling local address for the IPv6 gateway. Why can't the DHCP6 client then use that for monitoring? If I manually add it, it doesn't work.

    One thing about link local addresses is that you often have to specify the interface used to reach that address. For example, if you were to ping that address, you'd have to specify that interface. There are 2 reasons for this. One, there is no relationship between the address and the route to get to it, as with routeable addresses. The other is having duplicate link local addresses on different links is also valid. They only have to be unique on the link.



  • @JKnott OK, I'll try that but the original question still stands: why can't the DHCP6 code figure all this out by itself as it can for the DHCP4 WAN interface?

    I tried forcing the interface and it still doesn't work with the link local address.



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    @JKnott OK, I'll try that but the original question still stands: why can't the DHCP6 code figure all this out by itself as it can for the DHCP4 WAN interface?

    With IPv4, the address implies the interface. So, if you have a network 192.168.0.0 /24, then there will be an interface within that range. There is no such relationship between the link local address and interface. Some things can determine the interface, in response to received packets, such as with RAs. But if you are specifying a link local address, then you must specify the interface. As I mentioned, you could have the same LL address on multiple links. How is it to determine which interface you're referring to?

    Here's an example. My gateway address is the standard pfSense fe80::1:1. I'll ping with and without specifying the interface:

    With:
    ping fe80::1:1 -I eth0
    PING fe80::1:1(fe80::1:1) from fe80::76d4:35ff:fe5b:f5fa%eth0 eth0: 56 data bytes
    64 bytes from fe80::1:1%eth0: icmp_seq=1 ttl=64 time=0.250 ms
    64 bytes from fe80::1:1%eth0: icmp_seq=2 ttl=64 time=0.260 ms
    64 bytes from fe80::1:1%eth0: icmp_seq=3 ttl=64 time=0.252 ms

    Without:
    ping fe80::1:1
    connect: Invalid argument

    This is the same problem as you're getting when trying to use the link local address for monitoring.



  • @JKnott Hoever I've tried forcing the interface and it still doesn't work.



  • @lohphat

    Then you'll have to use some other address.



  • @JKnott I'm wondering what the monitoring process is. It may be that the IPv6 gateway doesn't respond to ICMP pings.

    So I've reverted to using the Google DNS address as the monitoring address altough I hate using someone's services as a monitoring point as it's unsolicited traffic. Using the local CPE gateway is still the obvious best solution.

    sigh



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    It may be that the IPv6 gateway doesn't respond to ICMP pings.

    The way to verify that is with Packet Capture. If you see them going out, but no response then that's the issue. You might also try with a known address, such as Google's DNS servers. You can use 2001:4860:4860::8888 and 2001:4860:4860::8844. You can also try pinging from the command line, remembering to specify the interface.



  • @JKnott Yeah, I tried to ping the gateway local link and 100% packet loss but pinging the Google DNS IPv6 addresses worked. Must be a Spectrum or a Motorola/Arris cabelmodem config.



  • @lohphat

    Where did you ping from? If pinging a link local address, you have to do it from a computer on the same link. This means you have to ping from pfSense, not a computer behind it.



  • @JKnott Correct. I pinged from the diagnostic menu in the pfSense UI and specified the interface as well. No joy.



  • @lohphat
    Why not do a trace route and find and use the first hop that responds as the target for the monitor?



  • @Napsterbater Because in a redundant path BGP environment, there may be multiple paths from the local POP and whichever I select may be a dynamic route which may sometimes be down for maintenance. This presumes Spectrum has a brain cell, but I digress...



  • @lohphat
    Though the first thing to show in a trace may just be the CMTSs GUA, thus just as good as the Link Local.

    Just because the LL doesn't respond doesn't mean the GUA wont. Though depends on the configuration of course



  • @lohphat

    Correct. I pinged from the diagnostic menu in the pfSense UI and specified the interface as well. No joy.

    I wonder why they would do that. Given it can't be pinged from beyond the local links, the usual security reasons for doing so don't apply.



  • @Napsterbater said in IPv6 working but I have to disable gateway monitoring:

    @lohphat
    Why not do a trace route and find and use the first hop that responds as the target for the monitor?

    If the next hop is also a link local address, he won't be able to ping it or any other LL address beyond the local link.



  • @JKnott My guess is that it's dependent on the OEM firmware IPv6 for the cablemodem, in my case a Motorola/Arris unit. It may not be the ISP's choice.

    I tried both UDP and ICMP pings and the next local IPv6 hop seems to be a reasonable ...::1 address so I will try using that for awhile instead of the Google DNS IPv6 address for gateway monitoring. I'll keep an eye on it.

    However this case might be interesting for the DHCP6 code owners to look oup for unrespondive link local WAN gateways and perhaps compensate by doing an ICMP traceroute and using the first hop's address.



  • @JKnott said in IPv6 working but I have to disable gateway monitoring:

    If the next hop is also a link local address, he won't be able to ping it or any other LL address beyond the local link.

    I just did some testing. My gateway link local address also does not respond to a ping. However, traceroute shows an address with a /128 prefix. Both that address and the link local have the same MAC address, so that is the address to use for monitoring. This demonstrates what I have often mentioned, while link local addresses are often used for routing, the interface will usually have a /128 prefix for a routeable address that can be used for testing, etc.



  • @JKnott Correct. My assigned /128 was 2604:2000:xxxx:... and the 2604:2000:xxxx::1 address was the first hop of the traceroute -- so that's what I now have as my monitoring address.

    Perhaps this can be considered a common IPv6 gateway config case and the DHCP6 code can be updated to automatically determine the upsteam gateway on its own without manual intervention for ease of configuration.

    The problem I see with the current manual intervention is that if Spectrum issues me a different /128 on the next cablemodem reboot and then the manual gateway monitor address may not be appropriate.



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    I tried both UDP and ICMP pings and the next local IPv6 hop seems to be a reasonable ...::1 address so I will try using that for awhile instead of the Google DNS IPv6 address for gateway monitoring. I'll keep an eye on it.

    If that address has a /128 prefix, I bet it has the same MAC address as the link local.

    IPv6 is a bit different from IPv4 in this regard. In addition to being able to use link local addresses for routing, an interface can have multiple addresses. For example, my desktop computer can have up to 17 addresses. This would be 1 link local and 8 GUA (7 privacy) and 8 ULA (7 privacy) I would have that many after my computer has been up for a week, as there's a new privacy address for each prefix per day, up to 7. Also, that /128 isn't really an interface address, as it's not in any prefix assigned to an interface. It is, however, a valid address for the device.



  • @JKnott said in IPv6 working but I have to disable gateway monitoring:

    If the next hop is also a link local address, he won't be able to ping it or any other LL address beyond the local link.

    If... Not all devices reply with their LL to ICMP (i.e. traceroute).. Such as pfSense itself. Hence a way to possibly sniff the GUA out.



  • @Napsterbater said in IPv6 working but I have to disable gateway monitoring:

    @JKnott said in IPv6 working but I have to disable gateway monitoring:

    If the next hop is also a link local address, he won't be able to ping it or any other LL address beyond the local link.

    If... Not all devices reply with their LL to ICMP (i.e. traceroute).. Such as pfSense itself. Hence a way to possibly sniff the GUA out.

    Also, further testing shows that /128 is not the next hop as I thought, at least not with my ISP. Regardless, the address can still be used for the monitor. I verified this by connecting my notebook computer directly to the modem and running the ip neigh show command, which lists all addresses on the local link. I didn't see that /128 address.



  • @JKnott

    I may have to give this a bit more thought (need some more beer). The link local address may be on the next hop, but since it's not with the prefix, it will be sent to the router, using it's MAC address. When I get a chance, I'll have to fire up Wireshark, to see what's actually happening. I find the networking tools in BSD to be limiting, compared to Linux.



  • Add :1 to the back of your gateway address and monitor that.



  • This post is deleted!


  • @chpalmer That's essentially what worked but I had to use traceroute to find the correct form of the address to monitor.

    IPv6 Link Local
        fe80::208:a2ff:fe0d:87ab%mvneta2
    IPv6 Address
        2604:2000:cfc0:1b:xxxx:yyyy:zzzz:9d5b
    Subnet mask IPv6
        128
    Gateway IPv6
        fe80::217:10ff:fe88:285b
    

    The next upstream hop via traceroute was:

    2604:2000:cfc0:1b::1
    

    However I can't be assured that I'll get the same IPv6 assignment after the cablemodem reboot; so a manual gateway monitor assignment, although working now, is not the optimal solution in case I get a different /128 after a CPE reboot or my ISP reassigning address space on their side. There needs to be a bit more intelligence in the DHCP6 code.



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    However I can't be assured that I'll get the same IPv6 assignment after the cablemodem reboot;

    That should not matter.. The address should still only be the same distance away and still monitorable.



  • @chpalmer What if my ISP decides to change the local DHCP6 pool to 2604:2000:cfc0:17... then the hop is not longer valid



  • @lohphat said in IPv6 working but I have to disable gateway monitoring:

    @chpalmer What if my ISP decides to change the local DHCP6 pool to 2604:2000:cfc0:17... then the hop is not longer valid

    Why not use the Google DNS server? That's not likely to change. Also, I doubt they're likely to change the router addresses.



  • @JKnott As someone who's run IT ops, it a matter of principle for me. I wouldn't want someone using my resources for unintended purposes. A kludge is a kludge -- the right solution needs priority, so I'll deal with the hand I'm dealt until the DHCP6 code gets a little smarter.


  • LAYER 8 Netgate

    @lohphat said in IPv6 working but I have to disable gateway monitoring:

    @JKnott OK, I'll try that but the original question still stands: why can't the DHCP6 code figure all this out by itself as it can for the DHCP4 WAN interface?
    I tried forcing the interface and it still doesn't work with the link local address.

    Is this what is not working for you?

    Works fine for DHCP6 on Cox.

    WAN_DHCP6 fe80::d62c:44ff:fe7d:c819 fe80::d62c:44ff:fe7d:c819%igb5 25.051ms 55.226ms 0.0% Online Interface WAN_DHCP6 Gateway



  • @Derelict I think it's a CPE issue not Spectrum, but that's just a guess.


Log in to reply