On 11/4/2010 11:42 AM, Bart Schaefer wrote:
> On Thu, Nov 4, 2010 at 8:53 AM, Les Mikesell<lesmikesell@xxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
