Open IPv6 Issues / questions

- will the fix for issue NUTM-7187 be included with 9.5?

- is there a fix in the works for IPv6 Connections where the WAN Port is supposed to use an address out of the delegated prefix? Currently users of such ISPs do not get any IPv6 address. (for esxample KPN netherlands)

- what about the ability to change/edit the UID for IPv6 Delegation Requests?

- what about long standing feature requests such as 6tunnel integration, lets encrypt - is that on the roadmap? Users, myself included had high hopes for 9.5 but this seems to be more than a maintance release.

 

thank you in advance.

  • Hi Le,

    Attached are the iptables rules (iptables --list) 

    iptables_ipv6_disabled.txt - IPv6 completely disabled
    iptables_ipv6_enabled.txt - IPv6 enabled and configured. Not working.
    iptables_ipv6_reconnected.txt - Reconnected PPPoE, not working.
    iptables_ipv6_reboot.txt - The magic reboot got my IPv6 up and running again.

    Not much difference in each output.

    Just like before, if I now recoonect my PPPoE, or even reboot, it doesn't work anymore unless I disable IPv6 for a while and reconfigure everything, and reboot.

    dhclient6 the cause?
    One thing I just noticed in yesterdays ipv6.log:

    2017:04:22-08:42:56 router ipv6_watchdog[4280]: Started dhclient6 -P (pid 4858)
    And a few minutes later:
    2017:04:22-08:51:15 router ipv6_watchdog[4280]: dhclient6 (pid 4858) has died

    So this made me think.. Was my connection working during that time? Did I reconnect my PPPoE connection?
    Since I currently have a working IPv6 connection after the reboot, I cheched the log:

    2017:04:23-10:16:58 router ipv6_watchdog[4290]: Started dhclient6 -P (pid 4851)
    Reconnected PPPoE, and my IPv6 connectivity was broken again. In the log:
    2017:04:23-10:39:17 router ipv6_watchdog[4290]: dhclient6 (pid 4851) has died

    This could be a problem.
    Can I try to start it manually? I found the binary in /var/sec/chroot-dhcpc/usr/sbin/ but -P is not a valid option?

    iptables.zip

  • Hi SandyRutten,

        Thanks so much for your help. It is appreciated.

        You are right in that we need to deal with "dhclient6 has died" and I will look into it.

        But in the meantime, the DHCPv6 and ICMPv6 traffics seems to be dropped as you can see

        from your previous 1781.Logs.zip in the captures (first and third) that did not work, there is

        no DHCPv6 traffics captured at all; while the second capture had DHCPv6 in it and we did get a prefix

        from DHCPv6 Server. So it is more probable that it is the iptables involved.

        Sorry to say it was my mistake not to mention to dump out both IPv4 and IPv6 iptables.

        Can you do the followings:

        1) Dump out the ip6tables (both working and non-working) and attach them to this thread

        2) Clear out the ip6tables (ip6tables -F) and try ping6 again

        Thank You so much and sorry for my omission. Thanks again.

  • Hello,

    Attached are the ip6table outputs. 
    Order of the logfiles: 

    ip6tables_not_working.txt - IPv6 was already in a broken state since yesterday, so not working.
    ip6tables_not_working_after_flushing.txt - Not working, after ip6tables -F
    ip6tables_after_reboot_working.txt - Working after a reboot.
    ip6tables_reconnect_pppoe_not_working.txt - Broken again after reconnecting PPPoE manually
    ip6tables_after_reboot2_not_working.txt - Still broken after a reboot.

    Did a quick compare on the logs, and the ip6tables output is the same in each case, extept the one after flushing it, that one is empty :)

    Still wondering why it sometimes helps to reboot, and sometimes not. I mean, if it is for example dhclient6 which crashes after reconnecting PPPoE, and doesn't get restarted anymore, I would think that *every* reboot would start dhclient6 again. But right now 1 out of .. multple reboots seems to do "fix" the connection.
    But that's what we are here for :)

    ip6tables.zip

  • Hi SanderRutten,

       Thanks and you are right. The ip6tables dumps are the same between

       ip6tables_after_reboot_working.txt and ip6tables_adter_reboot2_not_working.txt;

       Is there anyway I can log into your system and debug with you? If possible, it would

       be great. Thx.

     

       If I have access to your system while it is not working, then I would keep an eye on the

       default route since to get to "2a00:1450:400e:801::200e"; a default route might be needed.

       Also, I need to see how far to packet (ping6) travels the IP stack by duping out the counter on

       ip6table or on the eth1 interface.

     

       I would add the following rule to the ip6table:

       ip6tables --table filter --insert OUTPUT 1 -j LOG --log-prefix "ICMP_OUTPUT:" --log-level 7

       ip6tables --table nat --insert POSTROUTING 1 -j LOG --log-prefix "ICMP_POST:" --log-level 7

       // This allows us to see the ICMPv6 packet hits the OUTPUT chain (first) and POSTROUTING chain (last) before hitting the hardware interface 

     

        then for each ping6: dmesg command   to see the output of the log  

  • Hi Le,

    Just sent you the login details for my UTM. 
    Already added the two ip6table rules. Tried to ping6 google.com, dmesg output attached.

    Kind regards,

    Sander

    [32711.333847] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=553 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=57757 LEN=513
    [32711.456834] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=259 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=51561 LEN=219
    [32712.044663] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=521 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=65523 LEN=481
    [32712.051273] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=531 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=64634 LEN=491
    [32716.015921] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=64 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32716.340549] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
    [32719.602387] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=1
    [32719.602415] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=1
    [32720.014982] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=64 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32720.609683] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=2
    [32721.617441] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=3
    [32722.625206] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=4
    [32723.632963] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=27397 SEQ=5
    [32724.536578] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=448 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=61611 LEN=408
    [32724.546787] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=460 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=62161 LEN=420
    [32725.026543] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
    [32727.044946] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=560 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=56127 LEN=520
    [32727.064740] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=520 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=65449 LEN=480
    [32727.065520] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2a02:26f0:007b:048a:0000:0000:0000:1abd LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=62641 PROTO=TCP SPT=49897 DPT=80 WINDOW=64800 RES=0x00 SYN URGP=0
    [32730.169517] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2605:0380:0032:0351:0000:0000:0000:000e LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=55324 PROTO=TCP SPT=49898 DPT=5938 WINDOW=64800 RES=0x00 SYN URGP=0
    [32733.090322] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2a02:26f0:007b:048c:0000:0000:0000:201a LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=840252 PROTO=TCP SPT=49899 DPT=80 WINDOW=64800 RES=0x00 SYN URGP=0
    [32735.011479] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=64 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32742.415121] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=259 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=53744 LEN=219
    [32743.774562] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=1
    [32743.774595] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=1
    [32744.559620] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=108 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=547 DPT=546 LEN=68
    [32744.559640] ICMP_POST:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=108 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=547 DPT=546 LEN=68
    [32744.564693] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32744.774004] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=2
    [32745.009590] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=120 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=134 CODE=0
    [32745.509003] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32745.773781] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=3
    [32746.508762] ICMP_OUTPUT:IN= OUT=eth0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    [32746.581196] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2a01:0111:2003:0000:0000:0000:0000:0052 LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=656277 PROTO=TCP SPT=49923 DPT=80 WINDOW=64800 RES=0x00 SYN URGP=0
    [32746.773595] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=4
    [32747.421369] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
    [32747.611615] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2a01:0111:f330:1790:0000:0000:0000:0a01 LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=712704 PROTO=TCP SPT=49926 DPT=443 WINDOW=64800 RES=0x00 SYN URGP=0
    [32747.773307] ICMP_OUTPUT:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:0000:0000:0000:0001 DST=2a00:1450:4009:080f:0000:0000:0000:200e LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=33541 SEQ=5
    [32748.087268] ICMP_POST:IN= OUT=ppp0 SRC=2001:0981:9d6e:0001:d5c2:a358:31e0:a6e7 DST=2a02:26f0:007b:048f:0000:0000:0000:1abd LEN=72 TC=0 HOPLIMIT=63 FLOWLBL=719581 PROTO=TCP SPT=49927 DPT=80 WINDOW=64800 RES=0x00 SYN URGP=0
    [32749.564888] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
    [32750.007995] ICMP_OUTPUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:021a:8cff:fe49:1608 DST=fe80:0000:0000:0000:9584:0a8e:371a:73ee LEN=64 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0
    

  • Hello Le,

    thank you for taking care of leftover issues with IPv6. Just the other day i was talking to someone who has "Deutsche Glasfaser" (one of the larger direct fiber providers in north-west germany). Appearently they are using 6rd for IPv6 Dual Stack. Would supporting 6rd be more of a feature request or do you want to address this aswell within this bugfix? (i don't know much about 6rd as i did not run into this issue before)

    thank you again for you work on this.

    ---

    Sophos UTM 9.3 Certified Engineer

  • @  

    Thanks so much for your help for the capture (dmesg). The ping6 traffics was hitting the ppp0 3 times. But why there is no reply? This is still a puzzle.

    I sent a PM wrt login info. Thanks again.

    @ Ben

    Team decision is needed for 6rd support. I will pass your request on.

    Your comments and help are appreciated. Thanks again.

  • Le,

    will all these ipv6 improvement also go into the Sophos XG? I noticed that ipv6 is "completly broken" there. While i have no interested in switching, i was wondering if these things will be adressed there aswell.

    thank you again for the information and work on the ipv6 fixes on the UTM.

    ---

    Sophos UTM 9.3 Certified Engineer

  • Hi Ben,

     

    Since the architecture for XG is fundamentally different than the UTM, these changes are not easily portable to XG, and will have to be worked on separately.

    Please be assured though we are also working hard to improve the functionality on XG, it's just the fixes won't be a direct/easy port from UTM to XG.

  • Hi SanderRutten,

       Thanks a lot for allowing ssh into the UTM.

       Here is a quick summary:

       1) When I inherited the system from this morning, the ping6 to google.com did not work despite

            the facts all seemed to be fine with UTM.

            a) ip6table logging indicated that the ip6table passed all the ICMPv6 to the hardware interface

            b) The tcpdump indicated that it captured ICMPv6 on the hardware interface

            However there were never responses from google.com 

             UNTIL

        2) About 5 hours into debugging the system, i.e. verifying system thru:

            a) dmesg to see the ip6table logging of ICMPv6 traffic

            b) ip -6 route see the default route for PPPoE

            c) tcpdump -i eth1 for pppoe traffics

            d) tcpdump -i ppp0 for ICMPv6 traffics

            e) ps -elaf | egrep 'dhc|watch|ppp'

             They all indicated that the traffics were sent to the other end of PPPoE connection but there was no response,

     

             THEN out of no where, ping6 started to work like a charm. It has been going strong for over 1 hour now.

             I will let it go for a while and let you know when I am back tomorrow.

     

             Hence at this point, it is a puzzle while it started to work; everything from UTM seemed to indicate that it should

             work. So going forward, is there anyway can you confirm that the ICMPv6 packets do get on the wire, i.e.

             port mirroring on the upstream switch (if there is a switch between UTM and ISP) or somehow working with ISP to

             determine it; I just want to make sure that UTM sends out the ICMPv6 packet to eliminate upstream issue.

     

              That's all for now. Please let me know your comments, ideas or questions.

              Again, thanks so much for your help.