|
|
Evan Harris <eharris@xxxxxxxxxxxxx> said: > > > Okay, so you basically want a mode where OpenVPN ignores the source address on > > received UDP datagrams and doesn't use them to determine the address to send > > the next packet > > Unfortunately, that's not the problem. > > I need OpenVPN to pay attention to the destination ip of a recieved udp > tunnel packet, and use that as the source address of the outgoing tunnel > communication, even if it goes out of a different interface on the > multihomed host OpenVPN server. > > I did a bit more research, and it looks like a semi-solution might be to use > the --local option to force a bind just to the public ip. I'm assuming that > the replies will then come from the ip of the public interface in that case. > (I'll have to test it to check, but it seems logical). Think that would > work? > > Unfortunately, that's still only a partial solution, because I can see cases > where there might be more than one outside interface, and both would need to > be able to serve up vpn traffic, and would still need to pick the right > source ip to reply with based on the dest ip of incoming packets. > > If using the --local option does in fact work, then a "whole" solution might > be to add a parameter for openvpn allowing for multiple ip's to be bound at > the same time (for multiple interfaces) rather than to IN_ADDR_ANY when more > than one interface needs to be enabled for traffic. This would also give > more flexibility in configuration, in that you may not want to bind to all > ifaces, but need more than one. Basically OpenVPN supports --local which binds to a single interface. Without --local, it will bind to all interfaces. There's not really any middle ground right now. Binding to multiple IPs and using multiple sockets is a more involved change, though the infrastructure to do it will be in 2.0 which is under development right now. James |