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.

  • +1 please fix the IPv6 Prefix Delegation. It is currently not working with my provider (KPN The Netherlands). I am only getting a link local address via IPv6 and that's it. :(

  • Hi Ben, please see my answers inline below:

    Ben

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

     

  • In reply to bobbylam:

    bobbylam: thank you for answering my questions, its much appreciated.

    I found a problem with the current NUTM-7187 fix, i have forwarded my findings through our partner (the sophos utm first sends "renews" for the prefix, than "rebinds" and the prefix eventually becomes non functional after 24-48 hours)

    the KPN netherlands non ipv6 wan adress is an issue that rklomp has, we were working together on the prefix issue. I am sure he would be more than happy to provide you access to a test machine.

  • In reply to bobbylam:

    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

  • In reply to Ben:

    Hi Ben,

     

    Thanks for testing out our fix, we did indeed received your feedback and a developer is actually working on NUTM-7187 right now. We're currently investigating why the prefix eventually becomes unresponsive.

     

    As soon as we have something, I'll let you know!

  • In reply to rklomp:

    Hi Rene,

     

    The fix we provided to Ben SHOULD resolve the issue you described below with PPPoE (although as I said above it doesn't completely resolve Ben's issue, so we're still working on the final solution). Have you tried that fix, or are you running a stock 9.411?

     

    rklomp

    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

     

     

  • In reply to bobbylam:

    If i can take that as permission to share the fix with Rene il do that and test it.

    About the PPPoE fix, i have provided the partner with additional info (not sure if you received it yet)

    As a suggestion: It would help immensely if you would take into consideration of taking in bug reports like this without a running subscription and gold+ partner status. In the end it will benefit all customers in form of a more polished UTM and you as a company with a better product. Having to run and jump through loops trying to report an issue like this was not fun.

     

    i am pretty sure the problem that is still present is that the sophos doesn't properly interpret the ISP routers reponse to the prefix renews, after 8(or so) renews the sophos switches to rebinds in an endless loop. Eventually the prefix lease time runs out on the ISP router or something (at least thats my theory so far after spending 2 days with wireshark and rfc documents)

    so i see a renew after 2,5,10,22,40,80 ... 600 seconds .. and than just rebinds ... in the same manner, first doubling the seconds and hovering around 600-700 seconds (see partner info mail)

     

    Rene: see skype, test the patch and report back please ;)

  • In reply to Ben:

    Thank you Ben, that is extremely helpful info! The developer working on the issue was suspecting & investigating this same area as well, so looks like we're on the right track.

     

    Rene: Please check out the patch Ben sent you, and let us know if it resolves the PPPoE issue for you.

  • In reply to bobbylam:

    UTM stopped sending Rebinds sometime early yesterday, ipv6 prefix stopped working yesterday sometime after i last replied to this thread (it wasnt working this morning anymore)

    i am leaving the machine in this state, think your support is still logged onto the machine. Thanks again for this open communication, its much appreciated. 

     

    I provided Rene with the patch and waiting to hear back from him.

  • In reply to bobbylam:

    I installed the patch I received from ben, but it has not been solved.

    gateway:/home/login # rpm -Uvh ep-ipv6-watchdog-9.40-2.gffa2228.i686.rpm
    Preparing... ########################################### [100%]
    package ep-ipv6-watchdog-9.50-3.g64d8245.rb3.i686 (which is newer than ep-ipv6-watchdog-9.40-2.gffa2228.i686) is already installed
    gateway:/home/login # rpm -Uvh --force ep-ipv6-watchdog-9.40-2.gffa2228.i686.rpm
    Preparing... ########################################### [100%]
    1:ep-ipv6-watchdog ########################################### [100%]

    gateway:/home/login # /var/mdw/scripts/ipv6_watchdog restart
    Shutting down IPv6 Watchdog done
    Starting IPv6 Watchdog done
    gateway:/home/login # tailf /var/log/ipv6.log
    2017:04:11-09:46:58 gateway ipv6_watchdog[4378]: Stopping IPv6 address watchdog
    2017:04:11-09:46:59 gateway ipv6_watchdog[22269]: Starting IPv6 address watchdog
    2017:04:11-09:47:08 gateway ipv6_watchdog[22269]: Start of monitoring interface ppp0(ifidx 7)
    2017:04:11-09:47:08 gateway ipv6_watchdog[22269]: RA flags changed for interface ppp0(ifidx 7): NONE -> SENT,READY

    I am not receiving a IPv6 prefix. After making a capture on the interface I do not see a DHCPv6 Prefix request. What I see is a router solicitation every 5 seconds but no reply to it.

  • In reply to rklomp:

    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

  • In reply to PrakashSwamy:

    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é

  • In reply to rklomp:

    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

  • In reply to PrakashSwamy:

    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é

  • In reply to bobbylam:

    three things i forgot to ask:

    - RED (sophos to sophos, red device to sophos) over IPv6 only?  - pleaassseee! :-) 

    - Ability/Option to disable IPv6 for the SMTP Proxy -> When enabling IPv6, E-Mails beeing sent out will go over IPv6 if the Target MX Entry has an AAAA entry. We only want to use IPv6 for Websurfing, VPN etc. not for SMTP yet until it is properly assigned and managed

    - On our main business UTM we received a static IPv6 and Prefix from our Provider. The UTM does not have the ability/option to manually enter a Prefix that is statical assigned, if addresses out of the static prefix pool are "just" used, they won't have a route. Is this feature possible or non-standard?