Opened 5 years ago

Last modified 5 years ago

#867 new Bug / Defect

Static key connectivity issue between v2.3 and v2.4 in dual stack IPv4/IPv6 enviroments — at Version 1

Reported by: David Sommerseth Owned by:
Priority: major Milestone:
Component: Networking Version: OpenVPN 2.4.1 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: dual-stack ipv4 ipv6 static-key
Cc: tct

Description (last modified by David Sommerseth)

After some thorough testing with static key configurations a corner case was found. There are several workarounds, but I wonder if this warrants a fix.

Basically the issue is found on the v2.4 side in configurations with --proto {udp, tcp-server} where both sides uses the --remote option. In this scenario a reconnect attempt does not happen, thus only the first resolved IP address is used.


/etc/hosts:   host1
fc00::122:1     host1   host9
fc00::122:9     host9

Both hosts are configured with properly functional dual stack IPv4/IPv6.

A shared static key is generated and copied to both hosts using openvpn --secret test.key --genkey

OpenVPN configurations

[host1] # openvpn --dev tun --remote host9 \
                  --ifconfig --secret test.key \
                  --comp-lzo no --cipher AES-256-CBC
[host9] # openvpn --dev tun --remote host1 \
                  --ifconfig --secret test.key \
                  --comp-lzo no --cipher AES-256-CBC

Test case 1: Both sides using v2.3 OR v2.4

This setup works as expected. Using only v2.3 on both sides, IPv4 is preferred. Using only v2.4, IPv6 is preferred.

Test case 2: One side using v2.3, the other side v2.4

This setup basically fails and the following errors are logged:

Fri Mar 31 15:52:21 2017 TCP/UDP: Incoming packet rejected from [AF_INET6]::ffff:[10], expected peer address: [AF_INET6]fc00::122:1:1194 (allow this incoming source address/port by removing --remote or adding --float)

This is due to the v2.3 side tries to connect to the v2.4 side using IPv4, while the v2.4 tries to use IPv6. OpenVPN will not try to do any re-connect using any other IP addresses resolved by getaddrinfo().


  1. Add --float on the side which logs the warning above. This allows the remote side to change IP address
  2. Alternative, remove --remote on the side which logs the warning above. This does not enforce the remote side to come from a specific IP address.
  3. Alternative, use either --proto udp4 on the v2.4 side or --proto udp6 on the v2.3 side
  4. Alternative, add --keepalive 10 20 on the v2.4 side. This triggers a re-connect which will use another resolved IP address
  5. Alternative, switch to TCP using --proto tcp-client on the v2.4 side and --proto tcp-server on the v2.3 side. This also triggers a reconnect. The other way around does not work, as the v2.3 side will then listen to an IPv4 socket while the v2.4 side tries to connect using an IPv6 socket.


The issue seems to be that only the first IP address returned by getaddrinfo() is used in this configuration and never tries any other IP addresses. Most likely because this kind of configuration does not have any connect timeouts when --proto is either udp or tcp-server.

Due to the way this configuration works, the v2.4 side mistakes the IPv4 packets from the v2.3 server to be responses to the IPv6 packets sent. As long as --float is not configured but expects packets from a particular host, it will not accept those packets.

Another issue may also be that the v2.4 side should consider all resolved IP addresses from getaddrinfo() before rejecting packets not matching the first resolved IP address.

Change History (1)

comment:1 Changed 5 years ago by David Sommerseth

Description: modified (diff)
Note: See TracTickets for help on using tickets.