On Thu, 26 Sep 2013 00:51:57 -0700, Daniel Miller <dmil...@amfes.com> wrote:
> First - please confirm my assumption. Client connecting from whatever > his own internal LAN/external internet IP address, but has a routed VPN > IP assigned. Through the magic of IP, the client reaches my server-side > router. The router knows to pass connections on port "X" to the VPN > server. The VPN server decodes the packet and decides what to do. If > the packet is NOT intended for the VPN server, but instead another > server-side address, the packet gets forwarded. When THAT device > responds - it tries to reply to the address of the VPN client. Only if the VPN server is not doing NAT, thus exposing the VPN addresses to the end device, which seems to be the case in your setup. > Since it doesn't know how to reach that network it looks to its default > gateway - my router. Normally the router wouldn't know what to do with > it - but since I've manually told it VPN addresses belong to the VPN > server it sends it on - and then the VPN server encodes the response and > passes it back to the router to send it back out via the Internet. So you can set a static route on the device to the VPN address range pointing to the VPN server, and the device will use that route instead of the default when sending traffic to the VPN addresses. > Did I get that right? > > If that's the case...then it strikes me as inefficient and inelegant to > have the server-side network responses bouncing to the router, back to > the VPN server, and then back out the router. So...is there a way to > eliminate that link in the chain? Some iproute2 or iptables magic? Or > would I have to manually configure the VPN route on every server-side > machine (which I might be able to do via my DHCP...)? Or as usual am I > overthinking it and just leave it alone? If your router is also the VPN server (as in most setups) the problem disappears. I'm not sure whether Microtik can do that, but being a Linux box I would expect so. I may be wrong though. Otherwise, you have two options. The first is static routes as mentioned above, which is fine for few machines but impractical for many (there are ways to automate the setup, but it depends on your actual environment). The other option is to have the VPN server do NAT and hide the VPN addresses to the end machines; this way, they will see VPN traffic coming from the source IP of the VPN server and will thus naturally reply to that address directly. This works fine for traffic originated from a VPN address to a LAN device; however, if it is a LAN device that initiates a connection to an address in the VPN range, then you will still have LAN device -> router -> VPN server -> router -> ... since the LAN device has no route to the VPN addresses. If you want to avoid the router -> VPN server -> router ping-pong at all costs, you need either a route to the VPN on the LAN device, or have the router and the VPN server live on the same box. -- D. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
