I have a CentOS 4 server that acts as a gateway for a small LAN. The lower half of the 192.168.144 address space is the LAN on eth1, the upper half is the WAN on eth0, and the default route is to 192.168.144.254 which is my DSL router; this has been working fine for years.
However, it's recently become convenient to connect the server to a VPN from time to time, for which I've set up OpenVPN. This works for connections originating from the server itself, but breaks for machines on the LAN when accessing IPs in the ranges that are routed to the VPN. Connections to IPs not in the private network still work as before.
Can anyone advise what I may need to change to configure the server to forward packets to the VPN? Pointers to documentation are welcome. Thanks.
/etc/sysctl.conf has: net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0
On 11/3/10 8:00 PM, Bart Schaefer wrote:
I have a CentOS 4 server that acts as a gateway for a small LAN. The lower half of the 192.168.144 address space is the LAN on eth1, the upper half is the WAN on eth0, and the default route is to 192.168.144.254 which is my DSL router; this has been working fine for years.
However, it's recently become convenient to connect the server to a VPN from time to time, for which I've set up OpenVPN. This works for connections originating from the server itself, but breaks for machines on the LAN when accessing IPs in the ranges that are routed to the VPN. Connections to IPs not in the private network still work as before.
Can anyone advise what I may need to change to configure the server to forward packets to the VPN? Pointers to documentation are welcome. Thanks.
/etc/sysctl.conf has: net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0
You probably are forwarding packets to the other end of the vpn. Does whatever is on the other end have a route back to your 192.168.144.x range through that end of the vpn? Connections from the server itself will source from the tunnel address, not the LAN.
On Wed, Nov 3, 2010 at 7:05 PM, Les Mikesell lesmikesell@gmail.com wrote:
You probably are forwarding packets to the other end of the vpn. Does whatever is on the other end have a route back to your 192.168.144.x range through that end of the vpn?
Ah, that may indeed be the problem. I'm a bit rusty with this stuff. The CentOS box is doing IP forwarding, but that doesn't mean that it's actually acting as a NAT? On the far end, 192.168.144.0/255 would just use the default route, which is to the gateway for the network to which the VPN is connected. There's no explicit route for my LAN range.
Connections from the server itself will source from the tunnel address, not the LAN.
Well, yeah, that part I expected. I was presuming the return packets would go back to the tunnel address, which would send them to my server, which would then NAT them back to the original LAN source; but maybe that translation isn't happening where I thought it was.
On 11/4/10 3:39 AM, Bart Schaefer wrote:
On Wed, Nov 3, 2010 at 7:05 PM, Les Mikeselllesmikesell@gmail.com wrote:
You probably are forwarding packets to the other end of the vpn. Does whatever is on the other end have a route back to your 192.168.144.x range through that end of the vpn?
Ah, that may indeed be the problem. I'm a bit rusty with this stuff. The CentOS box is doing IP forwarding, but that doesn't mean that it's actually acting as a NAT?
No, NAT is something you do in iptables, and if you have done it, the setup is likely to be interface-specific.
On the far end, 192.168.144.0/255 would just use the default route, which is to the gateway for the network to which the VPN is connected. There's no explicit route for my LAN range.
Quick check is a traceroute from the remote server to a 192.168.144.x address. If it doesn't go into the tunnel interface you need to add a route for the range via the remote tunnel ip.
Connections from the server itself will source from the tunnel address, not the LAN.
Well, yeah, that part I expected. I was presuming the return packets would go back to the tunnel address, which would send them to my server, which would then NAT them back to the original LAN source; but maybe that translation isn't happening where I thought it was.
No, you can NAT at the tun interface but then the connections only work in one direction. Normally for LAN-LAN connections you want to maintain and route the private ranges and only NAT at the internet gateways.
On Thu, Nov 4, 2010 at 5:49 AM, Les Mikesell lesmikesell@gmail.com wrote:
Quick check is a traceroute from the remote server to a 192.168.144.x address. If it doesn't go into the tunnel interface you need to add a route for the range via the remote tunnel ip.
Hrm. When I try to add such a route on one of the machines I want to reach, I get "SIOCADDRT: Network is unreachable".
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route?
On 11/04/2010 07:50 AM, Bart Schaefer wrote:
On Thu, Nov 4, 2010 at 5:49 AM, Les Mikeselllesmikesell@gmail.com wrote:
Quick check is a traceroute from the remote server to a 192.168.144.x address. If it doesn't go into the tunnel interface you need to add a route for the range via the remote tunnel ip.
Hrm. When I try to add such a route on one of the machines I want to reach, I get "SIOCADDRT: Network is unreachable".
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
You can ad a line like:
push "route 192.168.144.0 255.255.255.0"
to the server's configuration file.
This will cause a route to be entered into the clients routing table upon connection.
On Thu, Nov 4, 2010 at 7:56 AM, Emmett Culley emmett@webengineer.com wrote:
On 11/04/2010 07:50 AM, Bart Schaefer wrote:
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route?
You can ad a line like:
push "route 192.168.144.0 255.255.255.0"
to the server's configuration file.
Thanks for the suggestion, but (1) I don't have control of the server configuration and (2) I'm not sure that would work anyway, as what I want is for packets that come *from* network 192.168.144.0 to (not) be routed over the VPN, except for those that originate from 192.168.144.1. Do I misunderstand what that push command will accomplish?
Regarding (1) I do have a local openvpn-startup script that runs when the VPN comes up, to which I could add my own route or iptables commands. In fact it currently contains: iptables -A FORWARD -i tun+ -j ACCEPT which I should have mentioned before.
On 11/4/2010 10:09 AM, Bart Schaefer wrote:
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route?
You can ad a line like:
push "route 192.168.144.0 255.255.255.0"
to the server's configuration file.
Thanks for the suggestion, but (1) I don't have control of the server configuration and (2) I'm not sure that would work anyway, as what I want is for packets that come *from* network 192.168.144.0 to (not) be routed over the VPN, except for those that originate from 192.168.144.1.
Normally routes work on the destination addresses, and if you don't want something to go there based on the source address, you block it with iptables. It is possible to route based on source addresses, but if you need to do that, you are probably doing something wrong.
Can you explain what you are trying to accomplish as an end result? That is, is the 192.168.144.1 host a different machine than the one acting as the vpn gateway? And what you want to happen if some other machine tries to connect to the address(es) routed through the vpn? Normally the addresses routed through a vpn would be private so it doesn't make much sense to send them to your default internet gateway. If you are routing a public address through a vpn, then out some remote internet gateway, things get weird and will depend on appropriate NATing to work at all.
Do I misunderstand what that push command will accomplish?
push route is an openvpn config statement on your end that tells the remote side to add the specified route (typically your LAN range) back through the tunnel when it comes up.
Regarding (1) I do have a local openvpn-startup script that runs when the VPN comes up, to which I could add my own route or iptables commands. In fact it currently contains: iptables -A FORWARD -i tun+ -j ACCEPT which I should have mentioned before.
Does this mean you have control of one side of the connection? Or that you have root access but someone else manages the openvpn config?
On Thu, Nov 4, 2010 at 8:53 AM, Les Mikesell lesmikesell@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.
On 11/4/2010 11:42 AM, Bart Schaefer wrote:
On Thu, Nov 4, 2010 at 8:53 AM, Les Mikeselllesmikesell@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.
On Thu, Nov 4, 2010 at 10:41 AM, Les Mikesell lesmikesell@gmail.com wrote:
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
Nope. There's my original routing, some explicit host routing for the P-t-P IP address and VPN server, a network route for 192.168.90.0, and network routes for exactly the public IP space of the VPN server network. There's nothing that consumes a larger swath of the public space.
If you remove those routes and add one just for the 192.168.90/24 range things should work the way you want.
That'd mean that neither my host nor anything else on my LAN uses the VPN for the VPN server's network. What I want is to exclude the rest of my LAN but leave my host itself unchanged. Which perhaps just isn't possible without way too much hoop jumping.
On 11/4/2010 9:50 AM, Bart Schaefer wrote:
On Thu, Nov 4, 2010 at 5:49 AM, Les Mikeselllesmikesell@gmail.com wrote:
Quick check is a traceroute from the remote server to a 192.168.144.x address. If it doesn't go into the tunnel interface you need to add a route for the range via the remote tunnel ip.
Hrm. When I try to add such a route on one of the machines I want to reach, I get "SIOCADDRT: Network is unreachable".
That means you don't already have a direct route to the IP you specified as the gateway address. You should have used the IP of the remote tunnel interface endpoint which should be reachable when the tunnel is up (ifconfig should show both your local ip and the ptp remote ip).
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route?
Packets go to the most specific route - so anything not specified in a route statement or connected directly will go to the default gateway. "route -n" will display the routing table and if you understand how netmasks work you can see where everything will go on the next hop.
On Thu, Nov 4, 2010 at 8:14 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 11/4/2010 9:50 AM, Bart Schaefer wrote:
Hrm. When I try to add such a route on one of the machines I want to reach, I get "SIOCADDRT: Network is unreachable".
That means you don't already have a direct route to the IP you specified as the gateway address. You should have used the IP of the remote tunnel interface endpoint
Yup, that's what I did use. I tried first the "P-t-P" IP and then the "ip addr" as read from the output of "ifconfig tun0", with the same results in both cases. On the remote machine, the route to the VPN IPs goes through the default gateway on the remote side, which is 192.168.90.254. Multiple layers of foolishness here.
Maybe the simplest thing is to change the question: How can I cause packets forwarded from my LAN to avoid the VPN and go out via the regular default route?
Packets go to the most specific route - so anything not specified in a route statement or connected directly will go to the default gateway.
Understood. The problem is that I want to split the route based on the source rather than the destination, for which I presume I need iptables rules.
At this point I think I should just thank everyone for their help and attempt to pester the administrator of the VPN server.
-
Bart Schaefer -
Emmett Culley -
Les Mikesell