LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
LinkBack Search this Thread
Old 04-05-2010, 07:44 AM   #1
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Rep: Reputation: 15
OpenVPN routing problems?


Hi,

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.

Code:
[root@vpn01 openvpn]# cat /proc/sys/net/ipv4/ip_forward 
1

[root@vpn02 ~]# cat /proc/sys/net/ipv4/ip_forward 
1
Here is my routing table from the OpenVPN server:

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
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.
 
Old 04-05-2010, 08:00 AM   #2
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Slackware 13.37, Debian Squeeze
Posts: 7,985
Blog Entries: 25

Rep: Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009
Quote:
Originally Posted by digimars View Post
In other words, I can't ping anything on the server's LAN.
What are you pinging from? From an IP node on one LAN to an IP node on the other LAN?

What is the difference between the OpenVPN server and the OpenVPN client-server?
 
Old 04-05-2010, 08:13 AM   #3
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
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.
 
Old 04-07-2010, 04:27 PM   #4
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
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?

Last edited by digimars; 04-07-2010 at 04:29 PM.
 
Old 04-07-2010, 04:52 PM   #5
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
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.
 
Old 04-07-2010, 04:59 PM   #6
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
The FORWARD chain on my server:

Code:
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"?

Last edited by digimars; 04-07-2010 at 05:08 PM.
 
Old 04-07-2010, 05:11 PM   #7
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
I've never understood people, which makes thigh more complicated for them selfs.

Can you make DEFAULT RULE = DROP, add only rules which ALLOW what you need.

2. Problem is not on client side, problem is on server side, because it looks like server doesn't forward packets to ITS LAN.
 
Old 04-07-2010, 05:22 PM   #8
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
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:

http://beginlinux.com/blog/2008/12/installing-openvpn/

Do you have an example script that I can use instead? I'm just starting out with iptables itself.
 
Old 04-07-2010, 05:28 PM   #9
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
Can you, please send here output of command:
iptables-save
executed on your server.
Change there any PRIVATE IP addresses, please.

Thanks
 
Old 04-07-2010, 05:31 PM   #10
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
iptables-save

Code:
[root@botcovpn01 ~]# iptables-save
# Generated by iptables-save v1.3.5 on Wed Apr  7 18:29:36 2010
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [102:10476]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -s 127.0.0.1 -i eth0 -j DROP 
-A INPUT -d 127.0.0.1 -i eth0 -j DROP 
-A INPUT -s 192.168.0.0/255.255.0.0 -i eth0 -j DROP 
-A INPUT -s 172.16.0.0/255.240.0.0 -i eth0 -j DROP 
-A INPUT -s 10.0.0.0/255.0.0.0 -i eth0 -j DROP 
-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 tap+ -j ACCEPT 
-A INPUT -i eth1 -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-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 
-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 
-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 Wed Apr  7 18:29:36 2010
# Generated by iptables-save v1.3.5 on Wed Apr  7 18:29:36 2010
*nat
:PREROUTING ACCEPT [1337:87440]
:POSTROUTING ACCEPT [1148:79134]
:OUTPUT ACCEPT [290:21061]
-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 
COMMIT
# Completed on Wed Apr  7 18:29:36 2010
just to clarify:

192.168.207.0/24 - network spat out by OpenVPN
10.10.202.0/24 - OpenVPN server's LAN
 
Old 04-07-2010, 05:51 PM   #11
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
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


Next, table NAT:
*nat
:PREROUTING ACCEPT [1337:87440]
:POSTROUTING ACCEPT [1148:79134]
:OUTPUT ACCEPT [290:21061]
-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

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.
 
Old 04-08-2010, 07:29 AM   #12
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
Thanks again. I do have forwarding enabled on both machines:

Code:
[root@vpn01 openvpn]# cat /proc/sys/net/ipv4/ip_forward 
1

[root@vpn02 ~]# cat /proc/sys/net/ipv4/ip_forward 
1
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

Last edited by digimars; 04-08-2010 at 09:01 AM.
 
Old 04-08-2010, 10:09 AM   #13
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
You know, according to this:
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  * * *
Packets did not leave your client. That is mean that your tunnel doesn't work.
Can you post output of:
1. ifconfig -a
2. route -n

On your OpenVPN client WITHOUT public IP, please.

Thanks
 
Old 04-08-2010, 10:34 AM   #14
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
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?

Last edited by digimars; 04-08-2010 at 10:37 AM.
 
Old 04-08-2010, 10:56 AM   #15
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14
Posts: 1,554

Rep: Reputation: 89
on your first post you said:
OpenVPN server:
eth1 - 10.10.202.2/24

There is no such networks like 192.168.20x.xxx on SERVER side, except for ONE IP=192.168.207.5=OpenVPN

Servers network is 10.10.202.xxx

If you want to check your tunnel, you should try to traceroute IP=eth1(server)=10.10.202.2

Am I right?
 
  


Reply

Tags
openvpn


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Error When converting Routing OpenVPN to bridge mode openvpn danmartinj Linux - Software 0 11-07-2009 05:44 PM
OpenVPN routing (via one VPN to another) Robsco Linux - Networking 6 04-18-2009 03:16 AM
routing using openvpn williebens Linux - Newbie 1 07-11-2008 09:28 PM
OpenVPN and Routing. Eightpock Linux - Networking 2 07-10-2008 06:48 AM
OpenVPN Routing problem groetschel Linux - Networking 4 04-28-2004 04:07 AM


All times are GMT -5. The time now is 02:16 PM.

Main Menu
 
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: @linuxquestions
Open Source Consulting | Domain Registration