Open IPv6 Issues / questions

Hi Ben, please see my answers inline below:

Ben said:

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

 [BL]: The fix for NUTM-7187 is not included in this current UTM 9.5 beta version. We are actively working on the fix right now though, so as soon as we have a confirmed fix it will be included in a subsequent release.

- 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)

[BL]: This should be supported today, unless the ISP is doing both stateless & stateful. Is that the case for you? If so, we are fixing that as part of NUTM-7187 as well.

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

[BL]: Unfortunately this isn't part of this 9.5 release.

- 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.

[BL]: Lets Encrypt is on our current roadmap, but it's mainly planned as a WAF feature. As for 6tunnel integration, it's currently not planned for any specific release.

 

thank you in advance.

 

Hi Bobby,

Normally the ISPs router will then request /48 prefix and use a /64 from that prefix for the wan interface and a /64for the lan interface. So there are no other global ipv6 addresses than the ones from that /48.

On the Sophos UTM, in my case I will only receive a link local IPv6 address via PPPoE. Using a tcpdump I have verified the UTM is not sending out a prefix request after the PPPoE has been established. Is it waiting for a advertised IPv6 address for the WAN interface first before it will do this? Because in this case it will never get it... And thus a IPv6 prefix will never be requested.

If you want to have a look at my Sophos VM, or need some tcpdumps of the PPPoE setup let me know!

Rene

Hi Rene,

From the debug logs you have pasted, it looks like the ppp0 interface hasn’t received any RA from the ISP end.

Unless an RA is received with the appropriate flags (M, O or A) set, dhclient6 will not be started for this interface on the UTM.

Please check if disabling and re-enabling the DSL interace on the UTM helps.

-Prakash

Hi Prakash,

That is correct. The ISP does not do RA i my case. If you want I can share the capture of the regular setup with the box provided by the ISP instead of the sophos. 
After setting up the PPPoE connection it should do a DHPCv6 request for the prefix immediately. No RA is received.

Regards,

René

Hi Rene,

I looked into the capture file you provided and found that the box provided by your ISP directly sends out DHCPv6 solicit messages with IA_PD option, immediately after PPP IPV6CP is successful. The box provided by your ISP is probably configured to always use DHCPv6 IA_PD when connecting to the server.

On the other hand, the Sophos UTM has a need to first do IPv6 Neighbor Discovery to understand if the server (ISP end) supports SLAAC or stateless/stateful DHCPv6. Based on the RA and prefix flags it receives from the server during IPv6 ND, it would then setup the dhclient6 appropriately to use SLAAC or DHCPv6 or both.

In the absence of ICMPv6 RAs, the current code doesn’t initiate stateful autoconfiguration by default. We will look into addressing this issue asap as a bug fix in a future release.

-Prakash

Thank Prakash. Really appreciate the response on the forum!

In this case no Neighbor Discovery is possible. I tried it, but no response from the ISP network. So best would be a statefull autoconfig as fallback when no RAs are received.

Thanks again! Can you keep me updated on the bug report?

Regards,

René

i realize there was easter holidays, but is there any ETA on the fix of the lost prefix? i am delaying a setup right now that would need it and thus trying to work a time table. Thank you in advance.

Hi Ben,

A "potential" fix should be available before EOD today (PST). Hope it works well this time... let us know how it goes.

-Prakash

thanks for the swift reply Prakash

Please feel free to install it on the sophos with the open ticket anytime. ill than copy it to my test machine aswell and report back here on both.

I have installed the fix (/root/fix-2.1/ep-ipv6-watchdog-9.40-2.gce849c7.i686.rpm) on the UTM.

The ppp0 interface did get the prefix correctly.  Let us keep monitoring the behavior now...

Thanks,

Prakash

Hi Prakash,

Does this new version also solve my issue?

Regards,
René

OK good news; the patch seems to fix the rebind/renew and the IPv6 prefix is responding again

bad news: the prefix changes on every reconnect, it seems to ignore DUID or generates a new one (speculation at this point) each time it connects.

Before this version the prefix always stayed the same (and also does with other routes connected) so this must be some side effect of the fix.

Edit: ok i made 2 wireshark dumps, with the old patch and the new patch, here are the differences:

old patch on pppoe reconnect:

solicit, advertise going on for the WAN Interface (solicit is without prefix delegation!), than a REBIND happens for the OLD Prefix, Cisco ISP Router replys and confirms the old prefix!

new patch on pppoe reconnect:

solicit, advertise happened (with prefix delegation!), it seems the cisco isp router than proposes a NEW prefix, Sophos sends a REQUEST with the new proposed prefix. sophos never tries to rebind on the old prefix.

remarks: this only happens on interface reconnect, when just applying the patch and restarting the ipv6 watchguard the old prefix is beeing used. The new patch seems to just request a new prefix through the solicit without trying to "get" the old one. When applying back the old patch and restarting the ipv6 watchguard the prefix won't change.

i have put these two pcap (one with the old patch 1.x, one with the current patch 2.1) on the sophos with the ticket in /home/login/pcap-testmachine1/ .. these are pcaps from my testmachine since i dont want to bring the connection on the other machine up and down as much.

OK good news; the patch seems to fix the rebind/renew and the IPv6 prefix is responding again

bad news: the prefix changes on every reconnect, it seems to ignore DUID or generates a new one (speculation at this point) each time it connects.

Before this version the prefix always stayed the same (and also does with other routes connected) so this must be some side effect of the fix.

Edit: ok i made 2 wireshark dumps, with the old patch and the new patch, here are the differences:

old patch on pppoe reconnect:

solicit, advertise going on for the WAN Interface (solicit is without prefix delegation!), than a REBIND happens for the OLD Prefix, Cisco ISP Router replys and confirms the old prefix!

new patch on pppoe reconnect:

solicit, advertise happened (with prefix delegation!), it seems the cisco isp router than proposes a NEW prefix, Sophos sends a REQUEST with the new proposed prefix. sophos never tries to rebind on the old prefix.

remarks: this only happens on interface reconnect, when just applying the patch and restarting the ipv6 watchguard the old prefix is beeing used. The new patch seems to just request a new prefix through the solicit without trying to "get" the old one. When applying back the old patch and restarting the ipv6 watchguard the prefix won't change.

i have put these two pcap (one with the old patch 1.x, one with the current patch 2.1) on the sophos with the ticket in /home/login/pcap-testmachine1/ .. these are pcaps from my testmachine since i dont want to bring the connection on the other machine up and down as much.

Hi Ben,

I guess I know what could be causing the prefix to change on every reconnect.

I have copied another fix to you UTM (/root/fix-2.2/ep-ipv6-watchdog-9.40-4.gce64053.i686.rpm) which might solve this problem. Please install it and let me know how it goes.

Thanks,

Prakash

Hello Prakash,

thanks again for the swift reply, this fix indeed seems to fix all the issues! It did a rebind on reconnect instead of getting a new prefix. 

I will now let this run for 2-3 days and than report back :)

THANK YOU! :-) and big thanks to any other developer involved in this fix! 

Hi Prakash, Ben, etc :)

Is it possible to receive this hotfix as well? I'd like to test if it now works with XS4ALL. Would love to have my SG125w fully up and running again :)
Since this is in the UTM 9.5 beta board, I can use the beta as base? Or did you install it on the latest 9.4?

Hi,

as long as Prakash is ok with that ill provide you with the patch. I am running on 9.4, i think Rene is running on 9.5 beta. Since the patch only patches the ipv6 watchdog files (i think) you should be OK with 9.5 beta.

Hi SanderRutten,

You are free to get the rpm from Ben.

However, please note that this fix was only verified for 9.411-3.1. But, as Ben said, it should (I am 'pretty' sure it would) work if installed over 9.5 Beta too.

-Prakash

One way to find out ;-)

sent you the patch earlier ago, please let us know if it works for you, 

works here on 9.4 (current) and 9.5 beta

A little bit lost, is probably the correct term :+ I had it working for a few minutes, but somehow I've lost IPv6 connectivity and can't get it back... Even after a factory reset.

My first attempt when I got it working: clean 9.5 beta, installed the patch, restarted the watchdog service, enabled IPv6.
Enabled IPv6 Default Gateway on my WAN interface, added a static IPv6 address to my LAN interface, and created a Prefix Advertisement for my LAN.
I didn't create a new default route myself, it was added automatically. Client received an IPv6 address in my /64 range, and I was able to go to ipv6-test.com. (I did notice that my clients IPv6 address was actually the LAN's interface address, not the clients privacy extension address ??)
When checking under Interfaces, the WAN interface showed DEFAULT GW <IPv4> | fe80::2a0:a50f:fc78:5530
For some reason it now only displays DEFAULT GW <IPv4> | :: 
Like it doesn't have a gateway anymore.

I forgot to write down some log/commands in my first attempt, so these are from my second attempt.
/var/log/ipv6.log
2017:04:19-23:15:15 router ipv6_watchdog[8749]: Installing default route via fe80::2a0:a50f:fc78:5530 for interface ppp0(ifidx 12)

Seems fine to me.

ip -6 route
default via fe80::2a0:a50f:fc78:5530 dev ppp0 proto ra metric 1024 expires 1578sec hoplimit 64

Seems also fine, the same LL address I got on my opnsense firewall.

Getting a little bit late now, so I will test again tomorrow.

I have not seen the "Installing default route" in my logs.

Attached are my PPPoE and IPv6 log files.

logfiles_20170420085819.zip

Checked my logs as well, and they are quite the same.

So.. I decided to start over. No factory reset yet, just config-wise.
Removed all my IPv6 settings on my interfaces, deleted Prefix for my LAN, disabled IPv6.
Re-applied the patch (I know, shouldn't matter), restarted the watchdog service, and reconnected the PPPoE connection.

Gave my LAN a static address 2001:981:9D6E:1::1
Re-created the Prefix Advertisement for my LAN.
Enabled the "IPv6 Default GW" on my WAN. (2017:04:20-12:10:38 router ipv6_watchdog[10859]: Installing default route via fe80::2a0:a50f:fc78:5530 for interface ppp0(ifidx 19))
WAN interface shows: DEFAULT GW 194.109.5.175 | ::
After reconnecting the WAN: DEFAULT GW 194.109.5.175 | fe80::2a0:a50f:fc78:5530

No working connection :(
So, why not try a reboot, solves everything right? Appearantly it does :O After a reboot I could imediately ping and surf to IPv6 hosts.

I saw something new in the ipv6.log: Started dhclient6 -P
Let's hope it keeps working now!
This is also in René's logfile, but I didn't see it in mine before. Attached are my ipv6.log and pppoe.log. Everything before 12:15 is before the reboot, and after 12.15 is after the reboot.

There is one thing I already noticed, my clients are using my LAN's address 2001:981:9D6E:1::1 as outgoing address. Is this expected behavior? Security wise? Or should a client always use their temporary privacy extension address? 

Logs.zip