On 11/4/2010 11:42 AM, Bart Schaefer wrote: > On Thu, Nov 4, 2010 at 8:53 AM, Les Mikesell<lesmikesell at gmail.com> wrote: >> Can you explain what you are trying to accomplish as an end result? > > On the server side of the VPN is the 192.168.90.0 LAN *and* (because > of routes pushed by the VPN server to my client) the public IP space > of the VPN server's network. That and the VPN server itself are > managed by an outsourced IT department. > > On the VPN client side is my CentOS host, which has two NICs. The > lower half of 192.168.144 is the wired LAN plugged in to eth0, on > which my server is 192.168.144.1. The upper half is routed to eth1, > on which my server is 192.168.144.253. The DSL router is .254 and > uses the rest as DHCP space (but that's not involved here as it routes > directly to the DSL). The DSL router is configured with a static > route entry that sends the lower half of 192.168.144.0 to > 192.168.144.253. (This is the part I'd forgotten about when I first > posted -- it's actually the router that's doing the NAT translation. > It's been literally years since I touched any of this stuff.) > > I can do anything I like with my host, and almost nothing with the VPN > server or remote network, except on a couple of individual machines > where I have root access and tried the explicit routing experiment. > > What I'm broadly trying to accomplish is that bringing up the VPN on > tun0 on my host doesn't break the ipforward routing from my LAN to any > part of the public IP space (including the part pushed to my host's > routing tables by the VPN server). If I can get the my LAN to *use* > the VPN for all the routes that are pushed to me, that'd be great. If > I can get *only* the CentOS host to use those routes and leave the > rest of my LAN alone, that'd be acceptable. If you look at the route table on your server after the tun interface comes up, you'll probably see that either your openvpn config or routes pushed from the remote have split the conceptual 'default' range in half with 2 routes that split the whole IP space in half with the next hop set as the tunnel. Since the most specific route wins, all traffic will then route into the tunnel even though your existing default route is still there. This is what the openvpn 'redirect-default' directive is supposed to do. If you remove those routes and add one just for the 192.168.90/24 range things should work the way you want. Or you could outfox it by adding 4 routes, each covering 1/4 of the IP range pointing to your local internet/NAT gateway. But, keep in mind that there may be some security policy that prohibits connecting to that destination LAN with split-tunneling. The people who set it up may want all internet connections going through the same firewall when anything is connected to that LAN. -- Les Mikesell lesmikesell at gmail.com