How to set a route for Eth1 (DHCP clients) to reach Tun0 (openvpn server)? CentOS
 

Hi Everyone,

I have openvpn tunnel setup between two CentOS servers. One of the CentOS servers also acts as a DHCP server for some client computers.

Server A= OpenVPN server
Server B= OpenVPN client (connects to Server A with OpenVPN)

The two CentOS servers can ping each other (172.16.0.0/24) via the tun0.

However, client computer connected to Server B (DHCP server) can't reach 172.16.0.1 (which is the OpenVPN server).

I think I am missing some routing in my "ip route show". Following is the full picture:

***********************************************************************

[root@static-host ~]# ip route show
172.16.0.5 dev tun0 proto kernel scope link src 172.16.0.6
172.16.0.1 via 172.16.0.5 dev tun0
172.16.0.0/16 via 172.16.0.5 dev tun0
169.254.0.0/16 dev eth0 scope link
10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1
default via 192.168.0.1 dev eth0

***********************************************************************
[root@static-host ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:F0:53:99
inet addr:192.168.0.114 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fef0:5399/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9221 errors:0 dropped:0 overruns:0 frame:0
TX packets:18571 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:880932 (860.2 KiB) TX bytes:3158462 (3.0 MiB)
Interrupt:59 Base address:0x2000

eth1 Link encap:Ethernet HWaddr 00:0C:29:F0:53:A3
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::20c:29ff:fef0:53a3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3469 errors:0 dropped:0 overruns:0 frame:0
TX packets:9342 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:619800 (605.2 KiB) TX bytes:461704 (450.8 KiB)
Interrupt:67 Base address:0x2080

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:14078 errors:0 dropped:0 overruns:0 frame:0
TX packets:14078 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:594081 (580.1 KiB) TX bytes:594081 (580.1 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.6 P-t-P:172.16.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:546 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:504 (504.0 b) TX bytes:303948 (296.8 KiB)

***********************************************************************

[root@static-host ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.0.1 172.16.0.5 255.255.255.255 UGH 0 0 0 tun0
172.16.0.0 172.16.0.5 255.255.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

***********************************************************************

What command can I issue to get this fixed? something along ip route add?

Note: There is no firewall service on both end. service iptables stop!
Note: I can't bridge eth1 and tun0 as DHCP server might mess up the other side.
Note: I can't do a push of "redirect-gateway def1" because then clients loose their IP as they send DHCP requests to Server A.

Thanks a lot

It looks like you have a good start on the tunneling, but there are some other things to look for.

1. It appears that you are using 10.x.y.z as one private network for clients on the other side of server B from the tunnel, and 192.168.0.x as a second private network on the same side of server B as the 10.x.y.z net. Packets arriving at server B will be routed to 192.168.0.1 unless they either belong 172.16.x.y, or are addressed to another address on one of the private nets.

2. It is not clear from what you have said how any replies will come back from server A. Such packets will have a destination address of 10.x.y.z or 192.168.0.x, and, depending on the routing table THERE, may or may not be sent back through the tunnel. It is essential that, when you tunnel between two machines, the network numbers at either end of the tunnel are different from each other, because the tunnel, in effect, joins them up.

3. To further complicate the picture, DHCP is a broadcast protocol (because, at the beginning of a DHCP exchange, a client does not possess an IP address). Forcing server A to route broadcast packets down the tunnel in addition to broadcasting them on local nets might take some further research; I am not certain about this.

Some quality time with tcpdump (running at each end of the tunnel) might shed further light on what is going wrong.

Thanks for the reply.

Your point #3 doesn't stand right. For DHCP "problem" that you mentioned it does not happen (by default) unless:
push "redirect-gateway def1" is set in server.conf.

I solved the problem by adding the ccd in server.conf. That does a push of the IP network needed and problem was solved.

No further routing is needed at all any any other level. Of course I am assuming iptables is set to OFF.

Thanks