Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 2 subscribers
  • Views 15691 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[BUG?] Intermittently losing IPv6 connectivity on WAN

JonEtkins
(UPDATE: It doesn't appear to be a problem with the WAN connection, but rather with the routing or firewall.  See post #6 below)

(UPDATE 2: Confirmed that MASQ'd IPv6 connections still work even while direct routing is broken.  See post #21)

I've noticed that every now and then I lose IPv6 connectivity to the internet from my UTM running v9.107-33.  I only notice this when certain web sites, that my PC acceses via IPv6, stop responding (Google and Facebook are the two most common indicators) - I don't receive any uplink failure notification from the UTM itself.

Until last week, I suspected that I had munged something in my IPv6 configuration, but I've spent the past few days concentrating on IPv6 and redoing my configuration to use my delegated /64 network without masquerading, and I'm now pretty damned certain that everything is kosher at my end.

However, just this evening I lost IPv6 connectivity again, and this time I was able to determine that I could still ping6 the UTM, but not anywhere past it, and traceroute showed nothing past that point either.  The UTM was still showing an IPv6 address assigned to its WAN interface, but it just wasn't getting anywhere.

I recalled reading a post that mentioned a possible problem with the IPv6 DHCP client, though I couldn't recall the specifics, so on a whim I decided to disable and then re-enable the WAN interface.

Sure enough, after it came back up again - with the exact same IPv4 and IPv6 addresses assigned - IPv6 connectivity was restored and traceroute once again showed the entire path.

Subsequently, I found the post that I was thinking of: trollvottel's response in this thread, but searching the logs for "dhclient6" failed to reveal any failures.  However, I did notice the following message in the IPv6 log each time I have stopped the WAN interface recently:
/var/log/ipv6/2014/01/ipv6-2014-01-27.log.gz:2014:01:27-23:20:57 astaro ipv6_watchdog[4403]: Failed to stop dhclient6 -P -d -N on eth1
which may suggest that the client was indeed not running at the time?

I guess I'll just keep an eye on it, and check for dhclient6 in the process list next time it happens, but if there's any other tracing or diagnostics that I can do, I'm all ears.


This thread was automatically locked due to age.
  • 0
    A delegated Prefix is never removed - only changed as that'd destroy configuration.
  • 0
    I'm quite willing to accept that my ISP may be doing something a little weird, but it does seem that the UTM is not handling whatever that may be, correctly.  I can see that the WAN interface gas a public IPv6 address, and I can ping out, but traffic is not being routed through.
  • 0
    Happened again in the early hours of this morning. Is there any additional logging I can turn on that might help identify the root cause?
  • 0
    What device is used as CPE on your end?

    There is an issue we already know about which is due to a bug in the used ISC dhclient which does not properly request a new prefix. At my Home-UTM this happens when the cable modem rebooted for whatever reason and therefore the integrated DHCPv6 server looses it's lease table. The exactly same issue can also happen with IPv4 cable modem if you power-cycle it and you won't get the same address. UTM won't notice that the link went down and keeps the previous IP which won't work anymore.

    I created an ugly workaround script that detects the issue by regularly pinging an external host but using a src-address from within the delegated prefix. When the ping fails a few times, the script deletes the dhclient lease table and restarts the IPv6 watchdog which will respawn the dhclient requesting a new prefix and everything works again.

    eth0 is the *internal* interface which has a static IP chosen from the delegated prefix.

    /etc/init.d/rc3.d/S99dhcpv6_ia_na_fix.sh
    #!/bin/bash

    IFACE=eth0
    ERRORS=0
    TOLERATE=18
    LOG=/var/log/ipv6.log
    RUN="/var/mdw/scripts/ipv6_watchdog restart"
    LEASES6=/var/chroot-dhcpc/var/db/*.leases6
    SLEEP=10
    TARGET=www.google.com

    (
    for (( ;; )); do
        SRCIP=`ip -6 addr show dev eth0 | perl -n -e'/inet6 (.*)\/\d+ scope global/ && print \$1'`
        ping6 -I $SRCIP -c 1 -w 1 -n $TARGET > /dev/null 2>&1 || (( ERRORS++ ))
        if (( $ERRORS >= $TOLERATE )); then
            echo "Fixing DHCPv6 by deleting lease file..." >> $LOG
            # Delete lease files
            rm -f $LEASES6
            # Restart the watchdog
            $RUN > /dev/null 2>&1
            ERRORS=0
            sleep 120
        fi
        sleep $SLEEP
    done
    ) > /dev/null 2>&1 &


    The script can only work with v9.200 BETA! Previous versions don't have the IPv6 watchdog mdw script.
  • 0
    The WAN port connects to the outside world via a Motorola SB6141 Cable Modem. I'm not sure that this is a lease problem - even when the routing is broken, I can still ping out from the UTM, so it obviously still has a valid IPv6 address, and my ISP still knows about it too.  Even after stopping and restarting the WAN interface or manually renewing the lease, I get the same address every time.
  • 0
    Just had a thought - I wonder if this is related to the fact that I'm using direct routing (i.e. no masquerading) for my internal IPv6 addresses. In order to disable masquerading for IPv6 while retain it for IPv4, I have the internal interface's IPv6 address defined as an Alternative Address on the interface.  Perhaps I'll try re-enabling MASQ for the LAN IPv6 and see if the problem goes away.
  • 0
    You probably can still ping because UTM uses the link-local address of the ISP as Gateway. The public IP most probably doesn't work properly. You could check by ping6 your UTM from external when the problem occurs. MASQ of course would help but it's only a work-around and does not solve the actual problem. Please also check the logs of your modem if it lost connectivity, rebooted or whatever.

    To properly and more easily MASQ only IPv4, just create and IPv4-only network definition and MASQ that one instead. No need for additional address stuff.
  • 0 in reply to JonEtkins
    Perhaps I'll try re-enabling MASQ for the LAN IPv6 and see if the problem goes away.

    Following up on this, I re-enabled MASQ for IPv6, and I haven't lost IPv6 connectivity in the past 36 hours.  In fact, I haven't even seen the WAN connection drop out during that time, which leads me to wonder which is the chicken and which is the egg - are WAN dropouts causing problems with native IPv6 routing, or vice versa?

    I'm going to switch back to direct routing and see if the problem returns.
  • 0 in reply to trollvottel
    To properly and more easily MASQ only IPv4, just create and IPv4-only network definition and MASQ that one instead. No need for additional address stuff.

    I presume you mean something like this? Isn't it generally recommended not to create definitions that are bound to specific interfaces?
  • 0
    OK, now I'm starting to nail it down, or at least confirm my belief that the problem is limited to direct (non-MASQ) IPv6 routing.  After I turned off MASQ for my LAN segment last night, this morning my WAN connection dropped out again, and sure enough, my LAN clients lost IPv6 connectivity to the outside world again at the same time.

    However...

    This time I fired up a laptop on my Guest network - which remains MASQed for both IPv4 and IPv6 - and lo and behold, it still has outbound IPv6 connectivity even while the LAN's direct routing is borked.

    Seriously folks, there seems to be something broken here, but as a lowly Home user, I don't have access to the support channels to raise this as a problem.  I'm rather surprised that I'm the only person noticing this - maybe I'm the only one using IPv6 native routing on a cable modem with an ISP that drops out occasionally - but it's 100% real and reproducible.

    (And once again, simply clicking the Renew button on the WAN interface resolved the problem._