On Thu, 2014-04-03 at 14:59 +0200, Nikos Mavrogiannopoulos wrote: > On Thu, Apr 3, 2014 at 8:41 AM, Barchan barchan <barchan75 at gmail.com> wrote: > > On Wed, Apr 2, 2014 at 4:05 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > >> Is it the UDP socket you worry about? In that case would it make sense > >> to allow setting an arbitrary address to bind on, or should the client > >> just bind the UDP socket to the same one TCP is using (see attached > >> patch)? > > A worry about both - TCP and UDP. For example if host has got 2 IP > > 10.0.0.1 and 10.0.0.100 (on one or many interface) you should be able > > to choose which one is source for all outgoing packets. > > My idea is to see in openconnect similar option to wget's --bind-address=ADDRESS > > I see. You'll need to convince David on that, or even better send a > nice patch :) I certainly find clean patches in 'diff -up' form to be more convincing than prose :) I'm not really sure I see the point in this. From the client side, OpenConnect is supposed to support roaming. If you take down one interface and bring up another while it's connected, DPD will soon kill the existing connection and it'll make a new one over the new link. As long as your route to the VPN gateway goes via an appropriate interface (and thus with the appropriate IP address), why would OpenConnect need to do anything special? Can you describe a circumstance in which you'd want OpenConnect to connect from an IP address *other* than the one that it would use by default according to the routing tables? Would you not also need SO_BINDTODEVICE or something similar? And for vpnc-script to preserve the route to the VPN server out the *correct* interface, rather than the default one as shown by 'ip route get' ? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140403/763decfb/attachment.bin>
