Re: [Openvpn-users] Re: Answering on the same interface where the request came from

[Jamie L. <ja...@sh...>]

James Yonan wrote:
> The NTP guys (another UDP server) had a bit of a low-grade burn over this:
> 
> http://bugzilla.ntp.org/show_bug.cgi?id=314
> 
> It seems the anti-IP_PKTINFO camp won out?

The NTP maintainer rejected it in favour of scanning the list of
interfaces and binding a UDP socket for each one.

Largely because he wants to use a portable approach (I don't see how
scanning the list of interfaces can be described as portable, but at
least the code structure is common among implementations).

But also some consideration of multicast, and NTP's baroque
authentication came up.  I have no idea how multicast interacts with
IP_PKTINFO.

Unfortunately, at the end of that thread, the problem of changing
interfaces (or changing addresses on interfaces) was still broken.

IP_PKTINFO works on Linux and sufficiently recent versions of Windows.
There is some kind of BSD equivalent, but it's a bit different.

It's quite simple to use: just copy the pktinfo from recvmsg() to
sendmsg() and outgoing packets go out the same interface as the
incoming.  But it's not portable.

For OpenVPN: I see just one thing to be careful of: you don't want
packets coming on the wrong interface to be able to steal a VPN link
until they've authenticated.

In other words you need to treat distinct pktinfos in the same way
that distinct source addresses are treated (or should be) for the
purpose of updating the destination of outgoing tunnelled packets.

It's not possible to solve this problem portably.  (Of course, OpenVPN
is not portable anyway because it depends on platform-specific tun/tap
interfaces).

But generally (beyond Linux, BSD and Windows 2003/XP), you will need
to (1) structure the code to use multiple sockets; (2) read the list
of local interfaces and local addresses on each (in a non-portable way
unfortunately, and be aware it's a many-to-many relation, so sockets
need to be bound to interfaces as well as local addresses where
supported); (3) re-poll the list periodically to detect changes.

That's quite a lot of work and still not fully portable (but it's the
best you can do).

However IP_PKTINFO (and the BSD equivalent) would fix the problem
quickly and simply on the most used platforms, and probably performs
better than multiple sockets on those platforms.

-- Jamie