Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I am building up a site-to-site OpenVPN tunnel between two locations. I am setting this up in two CentOS 5.4 boxes each containing two NIC's.
I can get the tunnel up and running, and I can ping across the tunnel, however, from the client end of the tunnel I can not ping anything behind the server end of the tunnel. In other words, I can't ping anything on the server's LAN.
On both servers, eth0 is the WAN side and eth1 is the LAN side.
OpenVPN server:
eth1 - 10.10.202.2/24
OpenVPN client-server:
eth1 - 192.168.204.1/24
I have IP forwarding enabled in the kernel on both machines.
[root@vpn01 openvpn]# ip route show
192.168.207.2 dev tun0 proto kernel scope link src 192.168.207.1
x.x.x.112/29 dev eth0 proto kernel scope link src x.x.x.115
10.10.202.0/24 dev eth1 proto kernel scope link src 10.10.202.2
192.168.204.0/24 via 192.168.207.2 dev tun0
192.168.207.0/24 via 192.168.207.2 dev tun0
169.254.0.0/16 dev eth1 scope link
default via 10.10.202.1 dev eth1
Here is my routing table from the OpenVPN client:
Code:
[root@vpn02 ~]# ip route show
x.x.x.115 via x.x.x.113 dev eth0
192.168.207.5 dev tun0 proto kernel scope link src 192.168.207.6
x.x.x.112/29 dev eth0 proto kernel scope link src x.x.x.116
192.168.2.0/24 via 192.168.207.5 dev tun0
192.168.1.0/24 via 192.168.207.5 dev tun0
10.10.202.0/24 via 192.168.207.5 dev tun0
192.168.204.0/24 dev eth1 proto kernel scope link src 192.168.204.1
192.168.207.0/24 via 192.168.207.5 dev tun0
192.168.206.0/24 via 192.168.207.5 dev tun0
10.10.4.0/22 via 192.168.207.5 dev tun0
169.254.0.0/16 dev eth1 scope link
Here are the portions of my server config that are sending down my routes:
Code:
server 192.168.207.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
# force the clients to use the internal LAN's DNS and WINS servers
push "dhcp-option DNS 192.168.1.22"
push "dhcp-option DNS 192.168.1.23"
push "dhcp-option WINS 192.168.1.22"
# advertise the routes for the LANs that we want the client to access
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 10.10.4.0 255.255.252.0"
push "route 10.10.202.0 255.255.255.0"
# reference our client congiguration directory for extra configuration
# information for the named client
client-config-dir /etc/openvpn/client2
route 192.168.204.0 255.255.255.0
I'm sure that the answer is right in front of me, but I can't seem to get it cleared up. I can't hit anything on the 192.168.1.0/24, 192.168.2.0/24, 10.10.4.0 or 10.10.202.0 networks from the client server.
I am pinging from my client-server to the other end of my VPN tunnel, which is on the vpn server. From 192.168.207.5 (client-server) to 192.168.207.1 (my OpenVPN server).
The difference is my OpenVPN server is using my server.conf file (it is the actual server), my client-server is using my client.conf file, but will have PC's connected to it via a switch.
I'm still looking for help on this if anyone has an idea.
I did try and do a traceroute from my client machine that's connected to the VPN server, where I was trying to reach the gateway of the OpenVPN server's LAN interface (10.10.202.1, the eth1 LAN interface of the OpenVPN server is 10.10.202.2).
Anyway, this is what I get:
Code:
[root@vpn02 ~]# traceroute 10.10.202.1
traceroute to 10.10.202.1 (10.10.202.1), 30 hops max, 40 byte packets
1 (192.168.207.1) 2.540 ms 3.487 ms 3.514 ms
2 * * *
3 * * *
4 * * *
5 * * *
..etc.
So at least it's trying to get there through the tunnel.
So I check the routes on the OpenVPN server again after I made some modifications:
Code:
[root@vpn01 openvpn]# ip route show
192.168.207.2 dev tun0 proto kernel scope link src 192.168.207.1
x.x.x.112/29 dev eth0 proto kernel scope link src x.x.x.115
10.10.202.0/24 dev eth1 proto kernel scope link src 10.10.202.2
192.168.204.0/24 via 192.168.207.2 dev tun0
192.168.207.0/24 via 192.168.207.2 dev tun0
169.254.0.0/16 dev eth1 scope link
default via 10.10.202.1 dev eth1
But if I think I'm reading this right, it looks like the 192.168.207.0/24 traffic is just going around in a loop on the server. Is that correct, and if so what do I need to do to fix it?
Server acts like any other routers - it receives a packet from client <192.168.207.1> which wants to go to 10.10.202.1. That means server has to take that packet and forward it to different interface <eth1>.
So you have provide it with iptables. Check, if forwarding is enabled and FORWARD chain has allow state in both directions on SERVER.
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth0 any vpn01 anywhere
0 0 DROP all -- eth0 any anywhere vpn01
0 0 DROP all -- eth0 any 192.168.0.0/16 anywhere
0 0 DROP all -- eth0 any 172.16.0.0/12 anywhere
0 0 DROP all -- eth0 any 10.0.0.0/8 anywhere
0 0 DROP tcp -- any eth0 anywhere anywhere tcp spts:netbios-ns:netbios-ssn
0 0 DROP udp -- any eth0 anywhere anywhere udp spts:netbios-ns:netbios-ssn
0 0 DROP all -- eth1 any !10.10.202.0/24 anywhere
1222 85246 ACCEPT all -- tun+ any anywhere anywhere
0 0 ACCEPT all -- tap+ any anywhere anywhere
0 0 ACCEPT all -- eth1 any anywhere anywhere
0 0 ACCEPT all -- any eth0 anywhere anywhere state NEW
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
On my client:
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 RH-Firewall-1-INPUT all -- any any anywhere anywhere
0 0 ACCEPT all -- tun+ any anywhere anywhere
Does that one line in the server rule mean "drop anything except for what's coming from 10.10.202.0/24"?
I apologize for being so boneheaded about this, and I do appreciate your help. I do believe that the problem is on the server, I'm just smacking my head against the wall trying to understand why.
What you see for the firewall rules I used from the example firewall script that came with OpenVPN, and I followed the walkthrough here:
So, your default rule is DROP: FORWARD DROP [0:0]
Therefor:
-A FORWARD -s 127.0.0.1 -i eth0 -j DROP
-A FORWARD -d 127.0.0.1 -i eth0 -j DROP
-A FORWARD -s 192.168.0.0/255.255.0.0 -i eth0 -j DROP
-A FORWARD -s 172.16.0.0/255.240.0.0 -i eth0 -j DROP
-A FORWARD -s 10.0.0.0/255.0.0.0 -i eth0 -j DROP
-A FORWARD -o eth0 -p tcp -m tcp --sport 137:139 -j DROP
-A FORWARD -o eth0 -p udp -m udp --sport 137:139 -j DROP
-A FORWARD -s ! 192.168.207.0/255.255.255.0 -i eth1 -j DROP
useless - remove it
Next:
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tap+ -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -o eth0 -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Replace it for the test ONLY with:
-A FORWARD -o eth0 -i eth1 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
Please, remove:
-A POSTROUTING -s 10.10.202.0/255.255.255.0 -o eth1 -j MASQUERADE
because eth1=10.10.202.0/255.255.255.0
-A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE
there is already rule like it.
Check also if you have "1" in /proc/sys/net/ipv4/ip_forward.
I made some of the changes you recommended, using the script that came with OpenVPN:
Code:
#!/bin/bash
# A Sample OpenVPN-aware firewall.
# eth0 is connected to the internet.
# eth1 is connected to a private subnet.
# Change this subnet to correspond to your private
# ethernet subnet. Home will use HOME_NET/24 and
# Office will use OFFICE_NET/24.
PRIVATE=192.168.207.0/24
# Loopback address
LOOP=127.0.0.1
# Delete old iptables rules
# and temporarily block all traffic.
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -F
# Set default policies
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
# Block outgoing NetBios (if you have windows machines running
# on the private subnet). This will not affect any NetBios
# traffic that flows over the VPN tunnel, but it will stop
# local windows machines from broadcasting themselves to
# the internet.
iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP
# Check source address validity on packets going out to internet
iptables -A FORWARD -s ! $PRIVATE -i eth1 -j DROP
# Allow local loopback
iptables -A INPUT -s $LOOP -j ACCEPT
iptables -A INPUT -d $LOOP -j ACCEPT
# Allow incoming pings (can be disabled)
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Allow services such as www and ssh (can be disabled)
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
# Allow incoming OpenVPN packets
# Duplicate the line below for each
# OpenVPN tunnel, changing --dport n
# to match the OpenVPN UDP port.
#
# In OpenVPN, the port number is
# controlled by the --port n option.
# If you put this option in the config
# file, you can remove the leading '--'
#
# If you taking the stateful firewall
# approach (see the OpenVPN HOWTO),
# then comment out the line below.
iptables -A INPUT -p tcp --dport 1194 -j ACCEPT
# Allow packets from TUN/TAP devices.
# When OpenVPN is run in a secure mode,
# it will authenticate packets prior
# to their arriving on a tun or tap
# interface. Therefore, it is not
# necessary to add any filters here,
# unless you want to restrict the
# type of packets which can flow over
# the tunnel.
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
# Allow packets from private subnets
iptables -A INPUT -i eth1 -j ACCEPT
# iptables -A FORWARD -i eth1 -j ACCEPT
# Keep state of connections from local machine and private subnets
iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT
# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o eth0 -i eth1 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
# Masquerade local subnet
# iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE
The weird part is, every time I run the script, the -A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE gets added again.
After running the above, here is the output of iptables-save to show what I'm talking about:
Code:
[root@botcovpn01 openvpn]# iptables-save
# Generated by iptables-save v1.3.5 on Thu Apr 8 08:27:17 2010
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [72:7006]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -d 127.0.0.1 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -p tcp -m tcp --sport 137:139 -j DROP
-A FORWARD -o eth0 -p udp -m udp --sport 137:139 -j DROP
-A FORWARD -s ! 192.168.207.0/255.255.255.0 -i eth1 -j DROP
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 137:139 -j DROP
-A OUTPUT -o eth0 -p udp -m udp --sport 137:139 -j DROP
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Thu Apr 8 08:27:17 2010
# Generated by iptables-save v1.3.5 on Thu Apr 8 08:27:17 2010
*nat
:PREROUTING ACCEPT [4407:265494]
:POSTROUTING ACCEPT [2689:182662]
:OUTPUT ACCEPT [611:45395]
-A POSTROUTING -s 10.10.202.0/255.255.255.0 -o eth1 -j MASQUERADE
-A POSTROUTING -s 10.10.202.0/255.255.255.0 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Apr 8 08:27:17 2010
Thanks again for your help on this.
I found this line:
-A FORWARD -s ! 192.168.207.0/255.255.255.0 -i eth1 -j DROP
and deleted it from my rules, restarted the box, and still can't ping or traceroute through
I thought that my tunnel is working though, as I can ping the other side at 192.168.207.1 from the client. But I can't ping 192.168.207.5 which according to the output below is my P-t-P IP.
Here is the output of the commands, along with the iptables-save one in case it helps:
Code:
[root@vpn02 ~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:01:02:35:C6:55
inet addr:x.x.x.116 Bcast:x.x.x.x Mask:255.255.255.248
inet6 addr: fe80::201:2ff:fe35:c655/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14867 errors:0 dropped:0 overruns:1 frame:0
TX packets:13270 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7057766 (6.7 MiB) TX bytes:1275968 (1.2 MiB)
Interrupt:201 Base address:0xc00
eth1 Link encap:Ethernet HWaddr 00:0C:F1:D0:1F:D9
inet addr:192.168.204.1 Bcast:192.168.204.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Memory:fc9e0000-fca00000
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:1121 errors:0 dropped:0 overruns:0 frame:0
TX packets:1121 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2205332 (2.1 MiB) TX bytes:2205332 (2.1 MiB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.207.6 P-t-P:192.168.207.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@bvpn02 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
67.221.119.115 67.221.119.113 255.255.255.255 UGH 0 0 0 eth0
192.168.207.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
67.221.119.112 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0
10.10.202.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0
192.168.204.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.207.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0
10.10.4.0 192.168.207.5 255.255.252.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.207.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 192.168.207.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 67.221.119.113 0.0.0.0 UG 0 0 0 eth0
[root@vpn02 ~]# iptables-save
# Generated by iptables-save v1.3.5 on Thu Apr 8 11:20:32 2010
*nat
:PREROUTING ACCEPT [828:124992]
:POSTROUTING ACCEPT [128:9320]
:OUTPUT ACCEPT [7734:434727]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Apr 8 11:20:32 2010
# Generated by iptables-save v1.3.5 on Thu Apr 8 11:20:32 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [12986:1020356]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A INPUT -i tun+ -j ACCEPT
-A FORWARD -j RH-Firewall-1-INPUT
-A FORWARD -i tun+ -j ACCEPT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 1194 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Apr 8 11:20:32 2010
I did find a helpful image for iptables at http://linux-ip.net/nf/nfk-traversal.png and what I'm curious about is that I don't have a rule for my nat table (on the server) for FORWARD or INPUT. Is that OK?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.