|
|
Evan Harris <eharris@xxxxxxxxxxxxx> said: > > I have an openvpn server that is multihomed. It has a private ip on the > eth0 interface, and an external public ip on eth1. > > I'm trying to setup laptops so there is no configuration requred wether they > are inside or outside the network, openvpn just establishes a connection and > works. > > So, I've configured the openvpn clients to always establish the tunnel to > the public ip address of the server. It should work, since the default > route inside the network will still be able to get there. > > The problem comes up from the fact that openvpn doesn't appear to reply to > the other end of the tunnel with udp packets having the same source address > as the destination of the original packets. Its sent replies have a source > ip address of the interface the reply packets were sent via. > > Normally that would be ok, because you can use the --float option and when > the replies from the server come back with a different ip, the peer (the > notebook) will see it and change the tunnel destination address to the > source of the packets, in this case the private ip of the server. > > Now here's the twist that causes the problem: we have a multilocation > internal network using frame relay. Many of the remote offices use a > wireless network internally, and many of the notebooks attach using those > links. > > Because of the security issues of the wireless networks, the wireless > routers are firewalled so they can't talk to internal machines directly, so > the only traffic allowed to pass from those routers are packets destined for > the public ip of the tunnel server. So we don't want to use the --float > option. > > I just want openvpn to reply with the same ip! Can it be forced to? > > Tested with openvpn 1.5.0. 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 -- instead you would like to force all datagram sends to be made to the address and port which was statically defined in the --remote and --port options? That's an interesting idea, though it seems that it would break NAT or any other mechanism along the path which rewrites source addresses as a hint to the recipient to switch over to the new address. Having said that, if it's really the right thing to do in your situation, it's a trivial patch, and I'd certainly consider adding it if it's deemed to have general usefulness. If you want to try it on your own and don't mind hacking the code, do this: Go to the function link_socket_set_outgoing_addr in socket.c About 11 lines down, change this line: lsa->actual = *addr; to: lsa->actual = lsa->remote; This will force all UDP datagram sends to go to --remote/--port, regardless of the source address on received packets. Let us know if it solves the problem. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |