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 |
All times are GMT -5. The time now is 08:45 PM. |