Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 2 subscribers
  • Views 15694 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.
Parents
  • 0
    OK, it happened around 5:23 this morning:
    Sat 02/01/2014  5:22:07.97 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Reply from 2001:41d0:8:e8ad::1: time=133ms 
    Reply from 2001:41d0:8:e8ad::1: time=133ms 
    Reply from 2001:41d0:8:e8ad::1: time=135ms 
    Reply from 2001:41d0:8:e8ad::1: time=134ms 

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 133ms, Maximum = 135ms, Average = 133ms
     
    Sat 02/01/2014  5:23:10.60 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Destination host unreachable.
    Destination host unreachable.
    Destination host unreachable.
    Destination host unreachable.

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
     
    Sat 02/01/2014  5:23:39.12 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
     


    Sure enough, when I look at the IPv6 log, I see: 
    2014:02:01-05:23:12 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:12 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:24 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:24 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:28 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:28 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:30 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:30 astaro radvd[4355]: resuming normal operation

    There's nothing interesting in the System log at that time, but it does appear that my WAN link went down briefly right then:
    2014:02:01-05:23:12 astaro kernel: [1504516.448118] e1000: eth1 NIC Link is Down
    2014:02:01-05:23:24 astaro kernel: [1504528.472377] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    2014:02:01-05:23:28 astaro kernel: [1504532.480116] e1000: eth1 NIC Link is Down
    2014:02:01-05:23:30 astaro kernel: [1504534.484690] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX


    So it seems that perhaps something is not recovering correctly if the default IPv6 route is interrupted.
Reply
  • 0
    OK, it happened around 5:23 this morning:
    Sat 02/01/2014  5:22:07.97 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Reply from 2001:41d0:8:e8ad::1: time=133ms 
    Reply from 2001:41d0:8:e8ad::1: time=133ms 
    Reply from 2001:41d0:8:e8ad::1: time=135ms 
    Reply from 2001:41d0:8:e8ad::1: time=134ms 

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 133ms, Maximum = 135ms, Average = 133ms
     
    Sat 02/01/2014  5:23:10.60 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Destination host unreachable.
    Destination host unreachable.
    Destination host unreachable.
    Destination host unreachable.

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
     
    Sat 02/01/2014  5:23:39.12 

    Pinging 2001:41d0:8:e8ad::1 with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    Ping statistics for 2001:41d0:8:e8ad::1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
     


    Sure enough, when I look at the IPv6 log, I see: 
    2014:02:01-05:23:12 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:12 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:24 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:24 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:28 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:28 astaro radvd[4355]: resuming normal operation
    2014:02:01-05:23:30 astaro radvd[4355]: attempting to reread config file
    2014:02:01-05:23:30 astaro radvd[4355]: resuming normal operation

    There's nothing interesting in the System log at that time, but it does appear that my WAN link went down briefly right then:
    2014:02:01-05:23:12 astaro kernel: [1504516.448118] e1000: eth1 NIC Link is Down
    2014:02:01-05:23:24 astaro kernel: [1504528.472377] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    2014:02:01-05:23:28 astaro kernel: [1504532.480116] e1000: eth1 NIC Link is Down
    2014:02:01-05:23:30 astaro kernel: [1504534.484690] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX


    So it seems that perhaps something is not recovering correctly if the default IPv6 route is interrupted.
Children
No Data