|
|
On Mon, 26 Mar 2007, Brett Serkez wrote: >> The clients are setup with two remote lines, plus remote-random. >> Unfortunately the (UDP) openvpn server always responds with >> its 'first' local IP address. If I hardcode a listen value >> for its 'other' local IP address then the connections all >> start working to that IP and fail to the first. > > My take on it is that the UDP packets followed the default route. I don't think its route that is the problem in this case - its that the inbound packets have a destination address of ip2, but the server sends replies from source address of ip1. If "listen ip1" had been specified on the server then that behaviour would be completely correct, but as it hasn't I would expect the server to use the inbound destination address as its source address (providing it is a sane address) Itw what would happen with TCP, I would expect the same from UDP. Its quite possible I'm missing some overriding reason why this is not the case here... [...] >> d) Run OpenVPN on one link or the other, never both, and have some >> script to switch manually > > Right, in theory this would be the default route. Otherwise, I > suppose one could setup a route back to the specific incoming IP, not > sure how you'd do this? In my case I have a PF state rule which would trap any 'correct' return packets and send them out the correct port (it works for other services fine). >> e) Find someone to change OpenVPN's behaviour or to explain what >> I'm missing > > It would be good to have a methodology to handle this situation. > Building on the last thought, I'm thinking the routing table would > need to be updated at both VPN creation and tear down, not sure how to > implement this. Would you have any idea why OpenVPN would not set its source address as suggested above? I've racked my brains and I cannot work out its rationale... -- David Brownlee -- abs@xxxxxxxx ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |