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

[James Y. <ji...@yo...>]

On Thu, 24 Feb 2005, Jamie Lokier wrote:

> 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.

Right, but that infrastructure is already there in the way that OpenVPN
must decide the destination address of an outgoing UDP packet based on the
source address of a previously received and authenticated packet.

> 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.

Exactly.

> 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).

True, there are a few areas where OpenVPN takes a lot of code to iron out 
differences between non-portable APIs, such as tun/tap, routing, and event 
polling.  But these are critical areas that must be addressed because 
every OpenVPN configuration is using these APIs.

IP_PKTINFO is not in the same category because it is only needed by people 
who want to run a UDP version of an OpenVPN server in a true multi-homed 
configuration.

> 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.

I agree that IP_PKTINFO is the cleanest and easiest to implement in
OpenVPN's case -- much more so than enumerating interfaces.

James