Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1277 closed Bug / Defect (notabug)

Providing IPv6 outside the tunnel -- wont connect with IPv6 address

Reported by: kenjiuno Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

I'm running OpenVPN server on company's linux host named ubunku (Ubuntu 18.04.4 LTS).

My company's gateway (router) has both fixed IPv4 global address and native IPv6.

And there is IPv6 support on my home.

So I want to use IPv6 for OpenVPN connection.

It is ok:

  • home(IPv4) to company(IPv4) OpenVPN Server

It is not good, having error:

  • home(IPv6) to company(IPv6) OpenVPN Server

OpenVPN Windows 10 client log:

Sat Apr 25 22:05:16 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Sat Apr 25 22:05:16 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Apr 25 22:05:16 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sat Apr 25 22:05:16 2020 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Apr 25 22:05:18 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Apr 25 22:05:18 2020 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:XXXX:XXXX:XXXX::bf5:11940
Sat Apr 25 22:05:18 2020 UDPv6 link local: (not bound)
Sat Apr 25 22:05:18 2020 UDPv6 link remote: [AF_INET6]2001:XXXX:XXXX:XXXX::bf5:11940
Sat Apr 25 22:06:18 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 25 22:06:18 2020 TLS Error: TLS handshake failed
Sat Apr 25 22:06:18 2020 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 25 22:06:23 2020 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Apr 25 22:06:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:XXXX:XXXX:XXXX::bf5:11940
Sat Apr 25 22:06:23 2020 UDPv6 link local: (not bound)
Sat Apr 25 22:06:23 2020 UDPv6 link remote: [AF_INET6]2001:XXXX:XXXX:XXXX::bf5:11940

I knew why...

This is wireshark captured log on my home Windows 10:

No.	Time	Source	Destination	Protocol	Length	Info
1	21:59:48	2400:YYYY:YYYY:YYYY:b42d:c192:906f:e3d4	2001:XXXX:XXXX:XXXX::bf5	UDP	76	58659 → 11940 Len=14
2	21:59:48	2001:XXXX:XXXX:XXXX:d809:87d0:6835:21b8	2400:YYYY:YYYY:YYYY:b42d:c192:906f:e3d4	UDP	88	11940 → 58659 Len=26

ubunku (Ubuntu running OpenVPN Server) has 3 global IPv6 addresses, and OpenVPN server chose wrong IPv6 address for responding to client!

ku@ubunku:~$ ifconfig eno1
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.100  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 2001:XXXX:XXXX:XXXX:d809:87d0:6835:21b8  prefixlen 64  scopeid 0x0<global>
        inet6 fdf2:82d2:d07::bf5  prefixlen 128  scopeid 0x0<global>
        inet6 2001:XXXX:XXXX:XXXX::bf5  prefixlen 128  scopeid 0x0<global>
        inet6 2001:XXXX:XXXX:XXXX:3617:ebff:feeb:29e2  prefixlen 64  scopeid 0x0<global>
        inet6 fdf2:82d2:d07:0:3617:ebff:feeb:29e2  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::3617:ebff:feeb:29e2  prefixlen 64  scopeid 0x20<link>
        inet6 fdf2:82d2:d07:0:d809:87d0:6835:21b8  prefixlen 64  scopeid 0x0<global>
        ether 34:17:eb:eb:29:e2  txqueuelen 1000  (イーサネット)
        RX packets 629233  bytes 153382016 (153.3 MB)
        RX errors 0  dropped 15553  overruns 0  frame 0
        TX packets 108970  bytes 24606509 (24.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16

2001:XXXX:XXXX:XXXX::bf5 is OepnVPN Server host published via router.

However OpenVPN Server chose binding address
2001:XXXX:XXXX:XXXX:d809:87d0:6835:21b8 for responding to client.

This is my /etc/openvpn/server.conf

port   11940
proto  udp6
dev    tun

ca          ca.crt
cert        server.crt
key         server.key
dh          dh.pem
crl-verify  crl.pem

ifconfig-pool-persist ipp.txt

server 192.168.123.0 255.255.255.0

push "route 192.168.2.0 255.255.255.0"
push "dhcp-option WINS 192.168.2.181"
push "dhcp-option DNS 192.168.2.1"

client-to-client
keepalive 10 120
comp-lzo

user  nobody
group nogroup

persist-key
persist-tun

status      /var/log/openvpn/server-status.log
log         /var/log/openvpn/server.log
log-append  /var/log/openvpn/server.log

verb 3

client (Windows, OpenVPN GUI v11.15.0.0)

client
proto udp6
remote 2001:XXXX:XXXX:XXXX::bf5
port 11940
dev tun
nobind
comp-lzo
tun-mtu 1500

key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
...
-----END ENCRYPTED PRIVATE KEY-----
</key>

I don't want to use local direction because:

  • last local seems to be used if multiple ones specified. not all of them.
  • proto udp6 accepts both IPv4/IPv6 very well for now.

Change History (3)

comment:1 Changed 4 years ago by kenjiuno

Changing from udp6 to tcp6 worked well!

proto  tcp6

comment:2 Changed 4 years ago by Gert Döring

Resolution: notabug
Status: newclosed

If the server has multiple IPv6 addresses, you need to configure it with --multihome. This will enable a more complex socket handling which will make it reply with the correct source address on UDP sockets.

For TCP, the kernel handles that, so then it "just works".

comment:3 Changed 4 years ago by kenjiuno

Thanks. It worked.

I have appended multihome option to /etc/openvpn/server.conf

port   11940
proto  udp6
dev    tun
multihome

I believe multihome is the option written in reference.

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

–multihome

Configure a multi-homed UDP server. This option needs to be used when a server has more than one IP address (e.g. multiple interfaces, or secondary IP addresses), and is not using –local to force binding to one specific address only. This option will add some extra lookups to the packet path to ensure that the UDP reply packets are always sent from the address that the client is talking to. This is not supported on all platforms, and it adds more processing, so it’s not enabled by default.Note: this option is only relevant for UDP servers.

Note that it is difficult to find out multihome description from howto: https://openvpn.net/community-resources/how-to/

Note: See TracTickets for help on using tickets.