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
    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?!?
Reply
  • 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?!?
Children
No Data