Opened 3 years ago

Last modified 3 years ago

#867 new Bug / Defect

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

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: tincantech

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.

Setup

/etc/hosts:

192.168.122.1   host1
fc00::122:1     host1

192.168.122.9   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 10.8.0.1 10.8.0.2 --secret test.key \
                  --comp-lzo no --cipher AES-256-CBC
[host9] # openvpn --dev tun --remote host1 \
                  --ifconfig 10.8.0.1 10.8.0.2 --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:192.168.122.1:1194[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().

Workarounds

  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 triggers a re-connect which swaps the IP address from IPv6 to IPv4. The other way around does not work, as the v2.3 client results in an IPv4/IPv6 address mismatch again. The v2.4 side expects an IPv6 address while the v2.3 side uses an IPv4 address.

Conclusion

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 (6)

comment:1 Changed 3 years ago by David Sommerseth

Description: modified (diff)

comment:2 Changed 3 years ago by David Sommerseth

Description: modified (diff)

comment:3 Changed 3 years ago by David Sommerseth

Description: modified (diff)

Sorry about the mess when updating the tcp-{client,server} stuff. My notes confused me.

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

I'm not sure if we can fix that (without introducing new corner cases). Need to think more about it.

It's good that you found the conditions to trigger the case, plus have documented the possible workarounds.

comment:5 Changed 3 years ago by tincantech

CC

comment:6 Changed 3 years ago by David Sommerseth

Cc: tincantech added
Note: See TracTickets for help on using tickets.