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

Hi,

I wonder why SSL VPN outgoing should be a problem on DS Lite. I know many people who use this. I'm using this scenario as well.

This would of course not work if the XG Firewall is behind such a DS-Lite WAN Connection. It needs dedicated IP.

But I can tell there are problems with the connect client and IPSec from behind a DS-Lite connection.

Check these threads:

https://community.sophos.com/xg-firewall/f/discussions/121891/connect-client-funktioniert-bei-manchen-usern-nicht

https://community.sophos.com/xg-firewall/f/discussions/122398/connect-client-ipsec-vpn-and-heartbeat-issues

I've lost focus on testing this lately but one day this will be on my task schedule again.

Hope you find a solution.

Thanks for your reply.
In fact we have several users which are using DS-Lite in their Homeoffice. None of them is able to connect via SSL VPN. 
If they switch to a hotspot from their smartphone the SSL VPN will work without any issues. So it's not a configuration issue.
There are different routers in use like Fritzbox 7490 or Vodafone Station, so I would exclude that it's router related. Users with a Telekom DSL Connection are without any issues, stable and fast. 

Our XG is behind an LWL-Gateway from Telekom. Public IP etc. 

Are you sure that you using DS-Lite and not maybe Dual Stack with IPv4 and IPv6? Could share you SSL VPN configuration with me? 

I'm using Port 443 UDP for SSL VPN. 

LuCar Toni Thanks for the info. 
I actually don't want to ask in other forums if we use a XG and this is the Sophos Support Forum? Beside that I already searched for this issue on many sites. But let us be honest, the Unitymedia or any other carrier forum is not that helpful. I'm looking for an technical appropriate answer from experts and not from some dudes who just click the connect button. Other XG customers like LHerzog is also looking for solutions, so I think it's the best place to ask here? At the OpenVPN Forum they suggest IPv6 VPN.

From my description above you should have noticed that the behaviour is kinda strange, or isn't it? I have two other colleagues which were not able to connect, they switched to a business contract with IPv4 at Vodafone and after that the VPN is fine. So it seems like it's related to the WAN connection itself and not to the configuration or router. 

If your vpn is working fine, could you please share your ssl vpn configuration? I'm wondering what could be the issue. It's no help for me if you say "I'm cool with my vpn" and don't answer a single question from me. 

Beside that, does the XG supports IPv6 to avoid DS-Lite issues? 

Basically you need to start to begin the debugging with packet captures of both ends. As my connection works fine, i am still expecting some issues with those Connect boxes of the ISP, but never could reproduce this. 

If you do a tcpdump on XG and dump the same connection on the Endpoint, you should be able to figure out, what could possible go wrong. 

I assume there is a issue with the general experience. See: https://www.borncity.com/blog/2020/03/27/breitband-anschluss-und-kein-vpn-im-home-office/

Yes, I already read this article and also the comments, but there are so many different solutions which may help. I can't do this kind of extensive troubleshooting with every of my "cable" users. I need one simple solution for all of them. So I was thinking of an IPv6 VPN

As you already mentioned, this kind of issues are nuts, because it seems like there is no single root cause. You are using the same router and carrier, also DS-Lite and there are no issues. We using the the "same" setup, but it fails though the configuration and client is working fine with a LTE hotspot. 

I will try to dump a connection and check it. Do you use UDP or TCP for your ssl vpn?

I can use basically every different kind of connection with no problem. So i tried in the last month nearly everything on XG end, and could connect. Same for colleagues.

Hi,

this setting is running for all our users. Lots of Unitymedia/Vodafone Cable Users in BW though.

Maybe this is somehow related to UDP 443 you have set up, but I would wonder why this should make the difference. We're using TCP 443 - wonder what LuCar Toni is using in his settings.

My personal router is FB 6940 Cable (non ISP device) which is using DS Lite, not dual stack.

ssl_vpn_config.ovpn:

ip-win32 dynamic
client
dev tun
proto tcp
verify-x509-name "C=DE, .......... CN=*.xxxxxxx.de"
route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
<ca>
Bag Attributes
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
</key>
auth-user-pass
cipher AES-256-CBC
auth SHA256
comp-lzo no
route-delay 4
verb 3
reneg-sec 0
remote xxxxxxx.xxxxxxx.de 443

I would suggest you post client and XG log of one failing connection here.

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

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

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.

Hey together,

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

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? 

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?

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. 

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. 

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

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.

LHerzog

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. 

LuCar Toni Do you have some further information about this topic?