OpenVPN Multihome UDP issue/heads up in 2.4



  • This is more of a heads up more then anything. And related to this old 2013 Topic here https://forum.pfsense.org/index.php?topic=63994.0 but will likely come up more with 2.4 since the only way to listen to IPv4 and IPv6 on UDP is to use multihome, and not be able to bind it to a particular interface.

    So in pfSense when you select the option to listen to UDP IPv4 and IPv6 on all interface the "Interface" option below is ofcourse ignored (probably should be hidden), and the config option multihome is added to the OpenVPN config.

    The problem is OpenVPN will reply using the IP of the interface closest to the client NOT the IP the client initiated the connection to.

    for example say you have 3 interface, WAN(10.0.0.1), LAN (10.0.1.1), OPT1(10.0.2.1) (no firewall all open, routing in place/ok for example). If a client connected to OPT1 tried to connect to OpenVPN using 10.0.1.1, OpenVPN traffic back to the client will be from 10.0.2.1, by default a client will ignore this traffic unless "float" is added to client config, (Note pfsense client config page does not have a predefined option for this, this would have to be added to the "Custom config" section)

    One thing I found in my research of this issue was the above linked thread here but I also found this below, which seems to suggest that OpenVPN is supposed to handle this "correctly" already when multihome is specified, as in the above scenario reply/respond from 10.0.1.1 not 10.0.2.1, but it does not seem that is currently the case.

    Frome https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

    –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 2: if you do an IPv6+IPv4 dual-stack bind on a Linux machine with multiple IPv4 address, connections to IPv4 addresses will not work right on kernels before 3.15, due to missing kernel support for the IPv4-mapped case (some distributions have ported this to earlier kernel versions, though).


Log in to reply