Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 2 subscribers
  • Views 15689 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
    It just did it again this morning.  dhclient6 is still running:
    root      2026  0.0  0.0   2608   992 ?        S    Jan27   0:00  \_ /usr/sbin/dhclient6 -P -d -N -cf /etc/eth1.conf6 -lf /var/db/et
     but I have no outbound IPv6 connectivity.

    The WAN interface looks the same as it does when everything is working:
    WAN
    [Up]
    on eth1 [66.68.11.161/21 | 2605:6000:ffc0:1f:149f:2732:8954:c348/128]
    MTU 1500 · DEFAULT GW 66.68.8.1 | fe80::215:f9ff:fe2a:18d9
    and simply stopping and restarting the WAN interface restores IPv6 connectivity.
  • 0
    After getting it back up, I realized I should have used the Support menu to dig a little further while it was broken.   But looking at it now while it's working, I notice both the Global and Link Local addresses on the WAN (eth1) have Valid and Preferred lifetimes of "forever".  If those are normal and correct, then dhclient6 probably doesn't enter into it since there's nothing to renew, so I'm even more puzzled what could be causing this loss of connectivity.
    2: eth1:  mtu 1500 qdisc hfsc state UP qlen 1000

        link/ether 00:15:17:0a:fe:c2 brd ff:ff:ff:ff:ff:ff

        inet 66.68.11.161/21 brd 66.68.15.255 scope global eth1

        inet6 2605:6000:ffc0:1f:149f:2732:8954:c348/128 scope global 

           valid_lft forever preferred_lft forever

        inet6 fe80::215:17ff:fe0a:fec2/64 scope link 

           valid_lft forever preferred_lft forever
  • 0
    What Modem/Router do you use in front of the UTM?
  • 0
    A Motorola "Surfboard" SB6141 Cable Modem.
  • 0
    Curiouser and curiouser.  It happened again this morning, and this time I determined that I can still ping remote IPv6 addresses from the UTM, but not from any client machines on the LAN.  I honestly can't say for sure if I even tried that before!

    So it appears that perhaps the problem lies in the IPv6 routing or firewall, not the WAN connection.  I've created a batch file to ping ipv6-test.com every 60 seconds and log it to a file, so hopefully I'll be able to determine exactly when it breaks next time, and be able to examine that timeframe in the UTM logs.

    Meanwhile, as usual, simply disabling and re-enabling the WAN interface resolved the problem.
  • 0
    Happened again this morning.  This time I verified the effect from two separate Win7 clients and from my 9.2 beta UTM, to be sure that the problem is not limited to one particular machine or even one particular OS.

    Here's the situation:

    • All clients still have their IPv6 addresses.
    • All clients can ping the IPv6 address of the LAN interface.
    • Clients cannot ping the IPv6 address of the UTM's WAN interface.
    • Clients cannot access any IPv6 addresses outside the LAN.
    • The UTM itself can ping/traceroute the IPv6 internet just fine.

    The clients' routing table appears fine:
    IPv6 Route Table

    ===========================================================================

    Active Routes:

     If Metric Network Destination      Gateway

     11     26 ::/0                     fe80::216:41ff:fe36:32b2 (This is the correct link-local address for the UTM)

      1    306 ::1/128                  On-link

     11     18 2605:6000:1007:c08d::/64 On-link

     11    266 2605:6000:1007:c08d::14/128

                                        On-link

     11    266 fe80::/64                On-link

     15    276 fe80::/64                On-link

     16    276 fe80::/64                On-link

     15    276 fe80::250:56ff:fec0:1/128

                                        On-link

     16    276 fe80::250:56ff:fec0:8/128

                                        On-link

     11    266 fe80::3285:a9ff:fe94:22e2/128

                                        On-link

      1    306 ff00::/8                 On-link

     11    266 ff00::/8                 On-link

     15    276 ff00::/8                 On-link

     16    276 ff00::/8                 On-link

    ===========================================================================

    Persistent Routes:

      None

    This time, I did have repetitive ping tests logging on two clients, so I should be able to pin down the time frame and dig into the UTM logs.  Will post more as I find it.
  • 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.
  • 0
    Interestingly, this time things did not right themselves automatically after I manually stopped and restarted the WAN interface - when it came back up it did not get an IPv6 address, and although the IPv6 Status tab shows no address for the WAN, it still shows my delegated prefix!
    Native over WAN
    Delegated Prefix: 2605:6000:1007:c08d::/64

    Maybe my ISP is doing some work this weekend, but how is it possible that I was still able to ping6 out from the UTM? [:S]
  • 0
    After my last post, I realized that my ISP was indeed having trouble with their DHCP6 server, because although I was still getting a delegated /64 network, my WAN interface was not getting a public IPv6 address.  So I re-enabled my SIXXS tunnel for the past few days.

    Even though my internet connection dropped out a few times during that time, the IPv6 tunnel recovered perfectly every time the link came back up.

    Then last night, I realized that I was once more getting a public IPv6 address from my ISP, so I disabled the tunnel and started using native IPv6 again.

    Until this evening, when the connection briefly dropped out again, and - you guessed it - after it came back up, I could still ping IPv6 addresses from the UTM, and LAN devices can still ping the UTM's IPv6 addresses, but IPv6 traffic is not being routed through the UTM to the internet.

    This does appear to be consistent and reproducible - has no-one else noticed similar behaviour?!?
  • 0
    Oh, and this time I simply clicked the "Renew" button on my WAN interface instead of toggling it down and back up, and IPv6 started routing correctly again.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?