Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 18 replies
  • Subscribers 28 subscribers
  • Views 5215 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

Support for IPv6 VPNs | DS-Lite | Unitymedia WAN Connection

Jonnie

Hey together, 

Simple Question: Does the XG supports VPN access with SSL or IPSec VPN and IPv6 ?

Background: We have several users which must use a WAN connection from Unitymedia or Vodafone (cable based) in their homeoffice.

The issue is, that these carriers are using DS-Lite, which is breaking the SSL VPN connection. No vpn connection is possible.

As a workaround we could use IPv6 VPN, if it possible with the XG. I didn't find any useful information regarding the documentation.

If there any other solutions, i'm happy for any ideas. 

Regards,

Jonny



This thread was automatically locked due to age.
  • 0 in reply to LHerzog

    That's awesome! Thank you very much for sharing your config. My config is nearly the same, except UDP. 

    Do you have any speed impediments through the use of TCP instead of UDP? For example: 100k VDSL at home, is this speed also possible through the tunnel depending on your WAN connection at your company? 

    I'm afraid to use TCP regarding the documentation from OpenVPN itself. The call it TCP Meltdown. But maybe this is the issue that I set UDP 443, which is also used by the Google QUIC protocol. Further there were several rumors that UDP VPN is struggling with DS-LITE. 

    I will look for an tcpdump

    What do you use? TCP or UDP and which Port?

  • 0 in reply to Jonnie

    I cannot tell about the performance impact between TCP and UDP in my situation because this has spimply been setup this way.

    I can tell this works very fine with web meetings and VoIP to SIP Server behind the firewall. There are no delays or quality issues due to VPN connection. And I would think that you'd usually see performance issues in audio if there were any. From my point of view this is working solid.

  • +1 in reply to LHerzog

    Hey together,

    After some further troubleshooting I finally found the issue. It belongs to basic network fundamentals which I didn't think about.  Zipper mouth 

    Through the encapsulation from IPv4 to IPv6 the header is using more bytes (40 instead of 20) which is not expected by the ssl vpn. Pakets are getting fragmented and no useful data is flowing between the xg and client. 
    I've added the parameter "tun-mtu 1300" at the client config and the vpn is working flawless. You can check your actual MTU here.

    Is there any chance to set the MTU at XG? IF we want to use Sophos Connect Client the configuration is obtain automatically and I can't change the MTU correct? 

  • 0 in reply to Jonnie

    thanks a lot for testing and sharing this!

    Waht is your Internet connection on the XG? Is it PPPoE?
    Can you please provide the MTU of your XGs WAN interface where VPN clients connect to? It this 1500, 1492 or even lower?

    In opposition to SG you cannot test the MTU size from firewall from shell nor GUI. Maybe Sophos has information about manual MTU discovery on XG?

  • 0 in reply to LHerzog

    We using straight ethernet and a Telekom fibre connection gateway, no PPPoE.
    I'm getting a MTU of 1500 from the MTU Test I linked above. 

  • 0 in reply to Jonnie

    You wrote:

    through the encapsulation from IPv4 to IPv6 the header is using more bytes (40 instead of 20) which is not expected by the ssl vpn. Pakets are getting fragmented and no useful data is flowing between the xg and client. 

    So the tunnel was actually established but no data flowing? I was reading this like the tunnel could not even be established.

    Our tunnel also ends on 1500 MTU interface inbound on XG. So why should this not happen to us here?

    Have you also tried this one here

    tun-mtu 1500
    fragment 1300

  • 0 in reply to LHerzog

    Correct! Tunnel was established and shows up at the active ssl vpn users at XG. But then you can't open any websites and the issues I described above. ICMP and DNS is fine, but anything else fails. Sometimes you can open randomly parts of a website, but not reproducible. It really fits to the technical background that the MTU is killing the connection. 

    LHerzog said:
    Our tunnel also ends on 1500 MTU interface inbound on XG. So why should this not happen to us here?

    Actual I don't have any clue. But I tested the fix with three different colleagues at their home offices, the vpn is working flawless. Happy for any ideas

    LHerzog said:
    tun-mtu 1500
    fragment 1300

    According to the OpenVPN documentation it should be better to use –tun-mtu 1500 –fragment 1300 –mssfix 

    But I have to ask a colleague for testing, because i'm using regular VDSL at my homeoffice.

  • 0 in reply to Jonnie

    Sorry for the late response. This end of the year is going crazy. 

    I tried the parameters from the OpenVPN documentation but without any success. A connection could not be established. 

    Didn't tried the parameters mentioned by you due lack of time. 


    But I did some further research about the root cause of this issue. Normally OpenVPN is doing a Path MTU Discovery to obtain the correct MTU Size. This will fail if you block ICMP requests at the XG. So I checked our configuration and yes the xg dropped ICMP requests at the WAN interface. I activated ICMP and tried to reach the WAN Interface by ICMP, all fine but the vpn still fails without the tun-mtu parameter. 
    Actual there is not that much information out there about Path MTU Discovery with DS-Lite. I'm not sure how the requests are handled between IPv4/IPv6. 

    Do you have some further information about this topic?