IPv6 support makes openconnect server vpn connection too slow

Question

I have set up an OpenConnect server (ocserv) on CentOS 8 that is quite fast. However, when I enable IPv6 on it by uncommenting the following line, it becomes painfully slow and upload becomes almost zero.

#ipv6-network = fda9:4efe:7e3b:03ea::/48

I tried enabling ipv6 forwarding and ipv6 masquerading, but it did not help.

It's worth mentioning that clients realize that IPv6 is supported by the server as they show the IPv6 address given to them by the server. For example, when connected to the server using openconnect the log says:

Connected as 10.10.10.15 + fda9:4efe:7e3b:6b40:f973:5a56:56a0:b1a8/64, using SSL + LZ4, with DTLS + LZ4 in progress

Tried disabling dtls with --no-dtls flag, but it didn't help.

I need the IPv6 support because some websites require IPv6 and if your ISP has IPv6 support, but your VPN server does not support it, then you are exposing your real IP address to the server, rendering VPN connection useless.

Does anyone know how should I enable Ipv6 support for the VPN server without affecting connection speed?

PS. Here's the connection details from test-ipv6.com when VPN is connected:

Test with IPv4 DNS record
ok (2.008s) using ipv4
http://ipv4.vm3.test-ipv6.com/ip/?callback=?
    
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
bad (2.011s)
http://ipv6.vm3.test-ipv6.com/ip/?callback=?
    
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (2.004s) using ipv4
http://ds.vm3.test-ipv6.com/ip/?callback=?
    
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).

If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (2.026s) using ipv4
http://ds.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
    
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (1.583s) using ipv4
http://216.218.228.115/ip/?callback=?
    
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
bad (3.007s)
http://[2001:470:1:18::115]:80/ip/?callback=?
    
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
timeout (6.014s)
http://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
    
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels. Double check to make sure that ICMPv6 Type 2 ("Packet Too Big") messages are not filtered by your firewall.
Test if your ISP's DNS server uses IPv6
ok (2.013s) using ipv4
http://ds.v6ns.vm3.test-ipv6.com/ip/?callback=?
(This is bonus credit)
    
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
Find IPv4 Service Provider
ok (1.695s) using ipv4 ASN 51167
http://ipv4.lookup.test-ipv6.com/ip/?callback=?&asn=1
    
Attempts to identify what Internet Service Provider you use for IPv4. This may be different from the marketing name you see in your local market; or may reflect a previous company name. The name shown reflects how it is known in the network operator community.
Find IPv6 Service Provider
timeout (12.962s)
http://ipv6.lookup.test-ipv6.com/ip/?callback=?&asn=1
    
Attempts to identify what Internet Service Provider you use for IPv6. When the IPv4 name and the IPv6 name don't match, it may suggest that you're using a tunnel; or some form of third party provider for IPv6.

The same test without VPN connection:

 Test with IPv4 DNS record
ok (0.311s) using ipv4
http://ipv4.vm3.test-ipv6.com/ip/?callback=?
    
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
ok (0.349s) using ipv6
http://ipv6.vm3.test-ipv6.com/ip/?callback=?
    
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (0.971s) using ipv6
http://ds.vm3.test-ipv6.com/ip/?callback=?
    
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).

If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (1.999s) using ipv6
http://ds.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
    
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (1.428s) using ipv4
http://216.218.228.115/ip/?callback=?
    
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
ok (2.009s) using ipv6
http://[2001:470:1:18::115]:80/ip/?callback=?
    
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
timeout (16.053s)
http://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
    
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels. Double check to make sure that ICMPv6 Type 2 ("Packet Too Big") messages are not filtered by your firewall.
Test if your ISP's DNS server uses IPv6
ok (3.017s) using ipv6
http://ds.v6ns.vm3.test-ipv6.com/ip/?callback=?
(This is bonus credit)
    
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
Find IPv4 Service Provider
ok (0.247s) using ipv4 ASN 44244
http://ipv4.lookup.test-ipv6.com/ip/?callback=?&asn=1
    
Attempts to identify what Internet Service Provider you use for IPv4. This may be different from the marketing name you see in your local market; or may reflect a previous company name. The name shown reflects how it is known in the network operator community.
Find IPv6 Service Provider
ok (0.204s) using ipv6 ASN 44244
http://ipv6.lookup.test-ipv6.com/ip/?callback=?&asn=1
    
Attempts to identify what Internet Service Provider you use for IPv6. When the IPv4 name and the IPv6 name don't match, it may suggest that you're using a tunnel; or some form of third party provider for IPv6.

ICMP Situation:
To check the PMTUD situation, I checked icmptypes on the server with these commands and the 'packet-too-big' icmptype doesn't seem to be blocked.

 firewall-cmd --get-icmptypes
 #firewall-cmd --info-icmptype=packet-too-big
 packet-too-big
  destination: ipv6

 #firewall-cmd --query-icmp-block=packet-too-big 
 no

Also, following this article as mentioned in the comments, I ran tcpdump on client and server, but I don't see any packet too big traces. On the other hand, the only time I see an error like packet too large is on the client when I connect to the server without the --no-dtls option. Like below:

Failed to read from SSL socket: The transmitted packet is too large (EMSGSIZE).
Failed to recv DPD request (-5)

@MichaelHampton I am not sure I understand what you said. Would you mind explaining more? — Mehdi Haghgoo, Feb 20 '21 at 05:55
The connection is to show when ipv6 is enabled. i don't know much how ipv6 works. Should I change the address to something else or do some other configuration step for ipv6? — Mehdi Haghgoo, Feb 20 '21 at 06:26
You should have received a block of IPv6 subnets from your ISP. If you did not, then stop and have a chat with your account rep. After you have your block, you just subnet them normally (not exceeding /64 of course). — Michael Hampton, Feb 20 '21 at 16:22
Did you try experimenting with the --base-mtu argument of openconnect? — Gerrit, Feb 24 '21 at 09:38

score 3 · Answer 1 · answered Feb 20 '21 at 16:42

3

ULA is not for routing to the internet. It will get dropped before leaving your network resulting in a bad user experience.

Remove the ULA net from ocserv configuration and replace it with one or more /64 from your address plan. These subnets are only for the VPN. For example:

ipv6-network = 2001:db8:3025:1407::/64

On VPN clients with a web browser, verify with a dual stack test such as http://test-ipv6.com/

You have the right idea about implementing IPv6. IPv6 awareness is necessary to secure your networks. Some networks require IPv6. An IPv6 only stack without NAT is a simpler design.

answered Feb 20 '21 at 16:42

John Mahowald

32,050
2
19
34

Actually, that website (when not connected to the vpn server) tells me that my ISP supports IPv6 but large packets fail. – Mehdi Haghgoo Feb 20 '21 at 17:23
Will an IPv6-only stack work for all needs nowadays? – Mehdi Haghgoo Feb 20 '21 at 20:41
Edit your question to add the details of the possible MTU size failures. Do you get ICMP packet to big messages? Is this in the VPN tunnel or native internet? http://test-ipv6.com/faq_pmtud.html – John Mahowald Feb 21 '21 at 21:29
Most organizations require dual stack to access both IPv4 and IPv6 internet. The v6 stack is simpler in that you don't need masquerade: give the VPN a /64, all clients public IPs from this range. – John Mahowald Feb 21 '21 at 21:36
Changed ipv6-network to 2001:db8:3025:1407::/64, but, the connection is super slow. – Mehdi Haghgoo Feb 22 '21 at 20:53
I think maybe the ipv6-network parameter inside ocserv.conf is supposed to be ULA, because that's the case with ipv4-network of the VPN that gives clients addresses from the 10.10.10.0 network. Isn't that true with IPv6? – Mehdi Haghgoo Feb 22 '21 at 22:14
2

@codezombie As both of us already said, that is not necessarily true. If you want to access the global Internet then you need to use global IPv6 addresses. ULAs are fine if you are only accessing internal networks. You also can use both, in the general case, though I'm not sure how exactly you would configure that in OpenConnect. – Michael Hampton Feb 22 '21 at 22:51
@codezombie, if large packets fail, you must realize that IPv6 does not have path fragmentation the way IPv4 does, and a tunnel, like a VPN, will shrink the path MTU, possibly requiring fragmentation in the path that IPv6 does not do. On a tunnel, you need to make sure you are using PMTUD, to allow your server to send the correct packet size in the first place, without needing to fragment when the MTU shrinks. You are given global addressing for a reason, so that you can expose your global address to the world. You use a firewall to protect your network, just like you do for IPv4. – Ron Maupin Feb 22 '21 at 23:36

IPv6 support makes openconnect server vpn connection too slow

1 Answers1