Opened 6 years ago

Closed 3 years ago

#1057 closed Bug / Defect (fixed)

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

comment:1 Changed 6 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 6 years ago by tct

subscribed

comment:3 Changed 5 years ago by serinalevis

spam

Last edited 5 years ago by Eric Crist (previous) (diff)

comment:4 Changed 5 years ago by takken3

spam

Last edited 5 years ago by Eric Crist (previous) (diff)

comment:5 Changed 4 years 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 4 years 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 4 years 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.
Version 0, edited 4 years ago by Gert Döring (next)

comment:8 Changed 4 years 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 4 years ago by Gert Döring

dup of #846

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

Resolution: fixed
Status: assignedclosed

At last!

FreeBSD 12.2-RELEASE is out, and has this fixed - I just upgraded my test host to

FreeBSD fbsd12.ov.greenie.net 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC  amd64

and can confirm that a UDP server with --multihome does the right thing - 3 IPv4 addresses, 2 IPv6 addresses, packets get properly replied to, no matter which address or family the client picks.

Close!

(Thanks, bz@freebsd)

Note: See TracTickets for help on using tickets.