IPv6 traffic stops every few days



  • I'm using Pfsense 2.1.4 with Time Warner Cable and requesting a /56. Every day or two, I notice that Ipv6 traffic from my Lan is not working to Internet hosts. If I login to Pfsense and try to ping the IPv6 default gateway from the firewall, it works. Gateway monitoring shows it as UP. Likewise, from PFsense's WAN Ipv6 IP I can get to the Internet. (Ping ipv6.google.com for example)

    However, hosts from my LAN networks can't get to the Internet during those times. If I run tcpdump I can see the IPv6 traffic hitting PFsense and actually going out to the WAN interface, but no reply is ever seen.

    I've noticed that this happens whenever the WAN IP DHCP lease expires and is refreshed. I don't see any log entries regarding IPv6 DHCP6 leases, so I believe that what's happening is that PFsense is only refreshing the IPv4 DHCP lease, but not the IPv6 DHCP6-PD allocation. I think that Time Warner sees this as my IPv6 host not being active and de-allocates the prefix or just stops forwarding traffic back to my network.

    I can get it to work again by rebooting PFsense, which, I presume causes another DHCP6 exchange and makes TW forward traffic again.

    Anyone run into something similar? Any thoughts about how I can make it so that I don't have to reboot Pfsense every day or two, in order to keep IPv6 traffic flowing?

    I notice there's a problem since my internal hosts (Macbook pro) get slow access to pages like Facebook or Google, which are IPv6 enabled. During this timeframe, PFsense and my hosts keep their IPv6 addresses, and therefore they prefer to use them to talk to the Internet. Only Pfsense itself (which gets a separate /128) is able to use IPv6 at those times.



  • I have not noticed this myself yet… I have TWC and have been using IPv6 with them for over a month now with /56. So far have 3 /64 subnets working with no issues.
    Now that being said, I know different markets have different results. I'm north of NYC and don't have issues, but heard of a fellow pfsense user having issues in NYC with IPv6.. It would lock up the router.

    IPv6 is not officially supported by the company's HSD/Level3 departments yet even tho its been rolled out (still rolling) on the backend... Not sure when it will be, probably 2015 sometime..

    For me, IPv4 lease is renewned every 12 hours and IPv6 is once a week.  Is your LAN setup as a Track interface?



  • Yes, I'm setup for track interface. I'm in the San Antonio market.

    I have 4 IPv6 networks behind PFsense, all setup to track from that WAN PD allocation.



  • i'm wondering if its local to your market

    Check this out, someone else is have a similar issue with a different router
    http://www.dslreports.com/forum/remark,29214432?hilite=san+antonio+ipv6
    http://www.dslreports.com/forum/r29207871-IPv6-and-native-addresses



  • That actually sounds likely, because rebooting fixes the problem AND I can see traffic egressing my WAN port. Pfsense is indeed forwarding that traffic, but TW is not sending replies back my way.

    I wonder if there's a workaround I can enable on pfsense to account for that quirk. I mean, other than rebooting.



  • maybe try manually renewal for the ipv6 wan? What happens if you disable and enable your wan interface?



  • I will try that next time around. In the past, if I made changes to the IPv6 config, it would cause the LAN side to not get the PD allocated until a reboot.

    Rebooting at least means it will work for sure.



  • I had the same problem here with pfSense 2.1.0 and .1.

    My ISP is Kabel Deutschland, a german cable ISP.
    My main router ist a a Fritzbox 6360 that delegates subnets to the pfSense via prefix delegation.
    On every DHCP renew IPv6 broke, so IPv6 lasted only a few hours etc…
    The ipv6 config on the pfsense just got lost.

    I switched to other routers behind the fritzbox 6360 and every works. So i stopped using pfSense. Don't know if it would work with 2.1.3 oder 2.1.4.
    Currently Iam using a Sophos UTM behind the Fritzbox und everything works.

    But it was exactly the problem described here!



  • Im actually having a similar problem after i got ipv6 up and running. Using pfsense 2.1.4 up-to-date, and every 4 days or so.. possibly when the lease expires pfsense looses its connectivity.

    Clients still gets delegated ipv6, but nothing passes the pfsense box, and the "normal" logs that im able to see does not show me anything useful.

    If i "reload" the wan interface, takes a few seconds and ipv6 connectivity comes back.

    Previous poster indicating something about pfsense not detecting the dhcp release, causing the ISP to drop the delegated net and causing the traffic to just drop out from the wan "to nothing" seems plausible.. Ive also noticed sometimes when this happens "radvd" is gone from the services page. Either reloading the WAN interface, or rebooting pfsense solves this and all is up and running for another few days.

    Should i tweak something so that the "gateway tracker" wont track the link local address, but rather some remote address or similar so that pfsense are able to detect something happening?

    C



  • I've been seeing what sounds like the same issue since I originally set up my pfSense box.  I'm using Comcast's residential service, though.  Every 4-8 days (I'm pretty sure my DHCP lease time is 4 days, but sometimes it seems to make one cycle OK) all ipv6 traffic heading from inside my network gets no response, although the pfSense box itself has fine ipv6 connectivity.  This is driving me nuts, as whenever something decides to route over ipv6 it starts timing out when the problem starts with no indication why.

    Rebooting the system brings the connectivity back up, and I never had this problem with the previous Apple Airport Express the pfSense box replaced.  I'm getting ready to disable ipv6 entirely to force all the client machines to use ipv4 only, or just ditch pfSense and go back to the old router.

    Any thoughts on what I can do to debug this would be greatly appreciated.

    EDIT: On a related note whenever the ipv6 stuff stops working I start getting a ton of snort alerts like:
    Jul 9 17:19:16 snort[70590]: [122:7:1] (portscan) TCP Filtered Portsweep [Classification: Attempted Information Leak] [Priority: 2] {PROTO:255} <internal ipv6="" address="" on="" the="" assigned="" subnet="">-> <external ipv6="" address,="" like="" google="">There ONLY appear when the ipv6 connection isn't passing traffic correctly.</external></internal>



  • I'm currently running pfSense 2.1.3 on Comcast and getting a /60.  I've been running fine for over 60 days.  On the initial 2.1 Release, I was solid for 146 days before upgrading.

    This issue of the DHCP-PD addressing disappearing was an issue in the 2.1 BETA's and it was resolved by the time 2.1 came out.  From the reports, it looks like the issue may be back with the release of 2.1.4.

    Q: For those on 2.1.4, were you OK on 2.1.3?

    Something change in 2.1.4 that may have caused this issue to reemerge?

    Just an observation.



  • I wasn't problem-free with 2.1.3, but I had the impression it wasn't nearly as much of an issue on the previous release.  I did at one point have a 2 week+ uptime with ipv6 working the whole time on 2.1.3, and I haven't made it past 8 days yet with 2.1.4.  It could just be a probability thing since 2.1.4 hasn't been out that long.

    I've had ipv6 connectivity issues of one form or another since I started using pfSense with 2.1.2.



  • Just remembered something that I should note ….

    I was experiencing a problem with the IPv6 addresses disappearing, due to a gateway event.

    To eliminate that problem I have:

    1. Disabled WAN Gateway Monitoring  (IPv4 and IPv6).
    2. Inserted a switch between the cable modem and pfSense to isolate it from interface bouncing if the CM restarts due to loss of signal on the DOCSIS side.


  • I just tested that if I disable DHCP6 on the WAN interface - save & apply, and then re-enable DHCP6 and save & apply, I get IPV6 forwarding back.

    It appears that requesting DHCP6 will restore IPv6 transit from Time Warner, lending credence to my theory that the problem is related to TW dropping the PD if Pfsense doesn't renew it when the IPv4 renewal happens.



  • @priller:

    Just remembered something that I should note ….

    I was experiencing a problem with the IPv6 addresses disappearing, due to a gateway event.

    To eliminate that problem I have:

    1. Disabled WAN Gateway Monitoring  (IPv4 and IPv6).
    2. Inserted a switch between the cable modem and pfSense to isolate it from interface bouncing if the CM restarts due to loss of signal on the DOCSIS side.

    Disabling WAN Gateway Monitoring seems to have resolved the issue for me. 20 days of uptime so far.



  • This is still a problem for me. It is not related to the cable modem reset issue reported elsewhere, since my pfSense IPv6 WAN interface is addressed statically, and is connected via a switch so there is no interface dropping anyway. A Cisco router in front maintains a TunnelBroker IPv6 tunnel permanently, effectively providing native IPv6 to the pfSense box and all clients behind.

    IPv6 routing works fine in both directions after the box (VM) is restarted, however every few days the routing stops completely for clients behind the firewall. The firewall itself can reach the Cisco router's IPv6 interface, but it WILL NOT route traffic out to the internet (or at least, it won't pass replies back - I've not sniffed the network to find out yet).

    Restarting the VM brings IPv6 back connectivity each and every time.



  • @leeph:

    This is still a problem for me. It is not related to the cable modem reset issue reported elsewhere, since my pfSense IPv6 WAN interface is addressed statically, and is connected via a switch so there is no interface dropping anyway. A Cisco router in front maintains a TunnelBroker IPv6 tunnel permanently, effectively providing native IPv6 to the pfSense box and all clients behind.

    IPv6 routing works fine in both directions after the box (VM) is restarted, however every few days the routing stops completely for clients behind the firewall. The firewall itself can reach the Cisco router's IPv6 interface, but it WILL NOT route traffic out to the internet (or at least, it won't pass replies back - I've not sniffed the network to find out yet).

    Restarting the VM brings IPv6 back connectivity each and every time.

    Sounds exactly like the issue I had.  I still don't understand why, but try disabling gateway monitoring.  I had also isolated the cable modem so the pfsense system never saw the drop but until I disabled gateway monitoring it would still stop routing traffic every few days even though I could ping out over ipv6 by sshing into the pfsense box.



  • Actually I think I've pinned down the issue - at least on my installation.

    Disabling gateway monitoring had no effect either way in my case.

    By packet sniffing I found that traffic was actually being routed out of one of my OpenVPN interfaces!

    I have two OpenVPN services running - one for remote teleworkers, and another one one a different port for users behind firewalls etc. On the interface running on a non-standard port, I had NOT defined any remote IPv6 networks, and so what I think was happening was that instead of just not routing any IPv6 networks over the tunnel, it was assuming I meant route ALL of them - as in " :: " meaning 'default gateway'.

    By defining an IPv6 network for that OpenVPN interface, IPv6 traffic has remained unaffected for several days now where I would have expected it to fail by now.

    What I don't quite understand is why there was a lag-time between the box being rebooted, and the problem re-starting each time.

    Anyway - CHECK YOUR OPENVPN configurations and make sure you have an IPv6 remote network defined, even if it's one that doesn't exist, otherwise pfSense gets its IPv6 knickers in a twist.



  • Hi Leeph,
    I've exactly the same issue as you! Suddenly, my IPv6 connectivity dropped and I also detected that outgoing packets are sent to the ovpns1 interface!?
    Could you please give more details about your fix?

    <update>Here is the route which affects my traffic:

    ff02::%ovpns1/0 fe80::200:24ff:fed0:6950%ovpns1 U 0 78423 1500 ovpns1</update>

    Tx!
    @xme


Log in to reply