weird routing problem

spartan1833

Hi,

I need an explanation as to why this is happening because I do not understand. I've been running openvpn for a number of years now and have 8 sites running site-to-site openvpn tunnels w/o issue.

I've recently stood up a new openvpn server (Ubuntu 12.04 LTS, openvpn 2.2.1) and configured it in a manner similar to another, older system (Ubuntu 10.10, openvpn 2.1.0). In my config, I have a ccd directory with a file for the client supported by this server. The file has an iroute directive for the LAN behind the client's router (also Ubuntu 12.04 LTS). Within the .conf file, I have routes for the client's subnet and am doing "push route xx.xxx.xx..." for those subnets - here's an excerpt:

port 1194
proto udp

dev tun0

... cert, dh info ...

server 10.56.0.0 255.255.255.0
client-config-dir /etc/openvpn/ccd
client-to-client

route 192.168.200.0 255.255.255.0

push "route 192.168.200.0 255.255.255.0"
push "redirect-gateway def1"
...

This config works w/o issue on the older systems. However, on the clients connecting to the 12.04/2.2.1 server, I'm seeing something really bizarre: if the vpn tunnel is up, laptops behind the client router cannot access resources from the client router forward; they cannot ping the router (it's also the LAN default gateway) and cannot access the Internet. They still can acquire an IP address from the client router (it has DHCP running on it) but that's about it.

When I stop the tunnel, laptops behind the client router can ping the router again though they cannot access the Internet (redirect-gateway in place and iptables forces all traffic the the tun adapter based on the postrouting rules that are set). During my investigation of this issue, I found a "weird" entry in the client router's route table:

...
192.168.200.0 255.255.255.0 10.56.0.5 tun0
192.168.200.0 255.255.255.0 0.0.0.0 eth1

On a hunch that this was a problem, I manually deleted the first one and within a couple of seconds everything worked - laptops behind the client router could ping the router and access the Internet. The problem re-asserted itself after a restart of the vpn process and was again resolved by manually deleting the route.

After a little trial-and-error, i found that if I removed the push "route 192.168.200.0 255.255.255.0" from the server conf. file and recycled the vpn process on the server that the problem went away. I have not been able to check (as of yet) to see if LAN resources behind the client router are available from the server side; hope to do that tonight.

This routing association does not show up in any other system that I currently manage, even though the conf. files for the older systems are set up like the excerpt shown above (iroute in ccd/file, route, push "route xxx") so I am wondering why this setup is different than the older ones - can anyone explain it to me?

Thanks...

maikcat

please post FULL configs used...

--iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omit‐
ted, defaults to 255.255.255.255.

This directive can be used to route a fixed subnet from the server to a particular
client, regardless of where the client is connecting from. Remember that you must
also add the route to the system routing table as well (such as by using the
--route directive). The reason why two routes are needed is that the --route
directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the
--iroute directive routes to the specific client.

This option must be specified either in a client instance config file using
--client-config-dir or dynamically generated using a --client-connect script.

The --iroute directive also has an important interaction with --push "route ...".
--iroute essentially defines a subnet which is owned by a particular client (we
will call this client A). If you would like other clients to be able to reach A's
subnet, you can use --push "route ..." together with --client-to-client to effect
this. In order for all clients to see A's subnet, OpenVPN must push this route to
all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accom‐
plishes this by not not pushing a route to a client if it matches one of the
client's iroutes.

spartan1833

server.conf

port 1194
proto udp
fragment 1440
dev tun0

ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
crl-verify /etc/openvpn/certs/crl.pem
dh /etc/openvpn/certs/dh2048.pem
tls-auth /etc/openvpn/certs/ta.key 0

server 10.56.0.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
route 192.168.200.0 255.255.255.0

client-config-dir /etc/openvpn/ccd
client-to-client
push "route 192.168.200.0 255.255.255.0"

push "redirect-gateway def1"
push "dhcp-option DNS 192.168.250.1"

keepalive 10 120
replay-persist /etc/openvpn/rp
cipher AES-256-CBC

max-clients 15
user nobody
group nogroup
persist-key
persist-tun

status openvpn-status.log
log openvpn.log
verb 6
------------------------------------------------
client.conf

client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca certs/ca.crt
cert certs/client.crt
key certs/client.key
ns-cert-type server
tls-auth certs/ta.key 1
cipher AES-256-CBC
mute-replay-warnings
log client.log
verb 6
fragment 1440
--------------------------------------------------
ccd:
iroute 192.168.200.0 255.255.255.0

--------------------------------------------------
In reading the excerpt you posted about the iroute directive, it seems that the server is in fact pushing the route to the client that owns the subnet which seems a bit weird. Again, none of my other systems have this issue and it goes away if I remove the push directive so ????

Thanks...

maikcat

a silly question...

you are pushing redirect-gateway , so why do you also push route for 200.0 network too?

for testing can you add

ifconfig-push 10.56.0.10 10.56.0.9

to your ccd file and see if your specific client gets 0.10 ip?

weird problem anyway.. :?

can you also post client logs? (specific the route part..)

Michael.

spartan1833

I'll get the logs soon but to answer your question - I've always been under the assumption that "redirect-gateway" forces your client-side Internet traffic out the server-side and that the push "route xx.xxx..." enabled access from other client systems (on different subnets) to resources behind the pushed route - is this incorrect?

Thanks...

maikcat

I've always been under the assumption that "redirect-gateway" forces your client-side Internet traffic out the server-side and that the push "route xx.xxx..." enabled access from other client systems (on different subnets) to resources behind the pushed route - is this incorrect?

thats twisted.... 🙂

server pushes routes to clients,
redirect gateway pushes 0.0.0.0 128.0.0.0 to your client meaning
route ALL traffic (except local one) via vpn

push 192.168.0.0 just sent a static route for network 192.168.0.0 to your client...
nothing more nothing less...

clearly redirect gateway overlaps route 192.168.0.0 ....

hope that clear it out.

Michael.

spartan1833

Clearer but still a little muddy :?

So, if I understand what you are saying, when I have the push "route xxx..." in my config that there is a routing conflict/loop due to what redirect-gateway does to the client routing table, correct?

So taking this a bit further - if I have another client system supported by this server - let's say its LAN is 192.168.201.0/24 and it is also a site-to-site setup, will users behind .201.0 be able to access resources behind .200.0 (say a mail server,etc.) w/o the pushed route?

Thanks again for you help with this - I feel that I know less about this software now than when I started working it years ago :oops:

maikcat

So taking this a bit further - if I have another client system supported by this server - let's say its LAN is 192.168.201.0/24 and it is also a site-to-site setup, will users behind .201.0 be able to access resources behind .200.0 (say a mail server,etc.) w/o the pushed route?

yeap, redirect gateway changes your default gateway... 🙂

Michael.

spartan1833

Alright then, thanks for the insight - I'll be testing again on Thursday and will post back if I have problems.

Appreciate the help... 😃

spartan1833

Hi again,

Just wanted to reply back and say that all was well - thanks again for your assistance 😃

maikcat

glad i have helped you...

closing topic

Michael.