Opened 3 years ago

Last modified 7 weeks ago

#1057 assigned Bug / Defect

--multihome for v4-mapped sockets on FreeBSD fails

Reported by: Gert Döring Owned by: Gert Döring
Priority: major Milestone:
Component: Networking Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

dual-stack bind (v6 socket)
two IPv4 addresses
incoming UDP packet
reply goes out with wrong source

we had this with Linux, seems it is also a problem on FreeBSD

TODO: find out which FreeBSD versions are affected (this came from pfsense), document shortcomings, open FreeBSD PR if needed

Change History (9)

comment:1 Changed 3 years ago by berni

pfSense 2.4.2-p1 (FreeBSD 11.1-RELEASE-p6), OpenVPN 2.4.4, proto udp + multihome

Client logs

2018-04-17 10:53:18 TCP/UDP: Incoming packet rejected from [AF_INET]192.168.16.10:1194[2], expected peer address: [AF_INET]x.x.9.164:1194 (allow this incoming source address/port by removing --remote or adding --float)

x.x.9.164 is a CARP address designated for OpenVPN, 192.168.16.10 is the external transport network address.

12:45:34.649106 IP 10.183.0.40.openvpn > x.x.9.164.openvpn: UDP, length 42
12:45:34.649241 IP 192.168.16.10.openvpn > 10.183.0.40.openvpn: UDP, length 50

Server logs

10.183.0.40 TLS: Initial packet from [AF_INET6]::ffff:10.183.0.40:1194 (via ::ffff:x.x.9.164%vmx0), sid=7014e677 11d4cfce

and then a handshake timeout.

Adding proto udp4 works fine

TLS: Initial packet from [AF_INET]10.183.0.40:1194 (via [AF_INET]x.x.9.164%), sid=fdefbc01 350cbeb3

It looks like this behaviour is sort of known in pfSense, in 2.4.3 they added an option in the GUI to explicitly select IPv4-only

https://redmine.pfsense.org/issues/8298

comment:2 Changed 3 years ago by tincantech

subscribed

comment:3 Changed 21 months ago by serinalevis

spam

Last edited 19 months ago by Eric Crist (previous) (diff)

comment:4 Changed 19 months ago by takken3

spam

Last edited 19 months ago by Eric Crist (previous) (diff)

comment:5 Changed 7 months ago by Gert Döring

Seems this was a FreeBSD kernel omission after all - we got a patch to test:

https://reviews.freebsd.org/D24135

comment:6 Changed 7 months ago by Gert Döring

So. Testing the patch from Bjoern.

  • unmodified 12.1-RELEASE-p3, compiled from source, with 3x IPv4 and 2x IPv6 addresses
    • server with proto udp6 and multihome
    • connecting to either IPv6 address
    • connecting to IPv4 addresses always results in "response comes from the first IPv4 address on the interface" (so, secondary IPs fail)
  • applying patch D24135 from above, rebuilding the kernel, rebooting
    • IPv6 still works, either address
    • IPv4 is completely broken, either address leads to write UDPv6: Invalid argument (code=22) on sendmsg()

comment:7 Changed 7 months ago by Gert Döring

chased this down to a logic mishap in the proposed patch, changing one || to a && makes it work. Waiting for a new patch to do the formal ACK on it.

Last edited 7 months ago by Gert Döring (previous) (diff)

comment:8 Changed 2 months ago by Gert Döring

The FreeBSD people have now merged this in

commit rS364018: IPV6_PKTINFO support for v4-mapped IPv6 sockets (authored by bz)

This is now in "CURRENT" (which will eventually become 13-RELEASE). I've been told that this will be pulled to stable/12 in about 1-2 weeks, and eventually hit 12.2-RELEASE.

So - if you OpenVPN users get bit by this, upgrade to 12.2-RELEASE :-)

comment:9 Changed 7 weeks ago by Gert Döring

dup of #846

Note: See TracTickets for help on using tickets.