LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
Reload this Page OpenVPN routing problems?
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
Page 2 of 3 1 2 3
  Search this Thread
Old 04-08-2010, 12:31 PM   #16
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15

Yeah, you're right, the IP of the LAN side of the server is 10.10.202.2.

I was just thinking that I should be able to ping the other end of the tunnel with what the OpenVPN server assigns itself as it's IP in that tunnel.


I restarted openvpn from both the client and the server from the command line, and I'm getting this on the server:

Thu Apr 8 14:01:09 2010 client2/x.x.x.116:45573 MULTI: bad source address from client [x.x.x.116], packet dropped

So I am currently looking into that.

I also ran into a tip about running tcpdump on the tunnel interface, so I did so on my server while pinging from the client, and I am getting that traffic in it looks like:

Code:
[root@botcovpn01 ~]# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:14:35.873256 IP 192.168.207.6 > 192.168.207.1: ICMP echo request, id 15631, seq 1, length 64
14:14:35.873313 IP 192.168.207.1 > 192.168.207.6: ICMP echo reply, id 15631, seq 1, length 64
14:14:36.871767 IP 192.168.207.6 > 192.168.207.1: ICMP echo request, id 15631, seq 2, length 64
14:14:36.871792 IP 192.168.207.1 > 192.168.207.6: ICMP echo reply, id 15631, seq 2, length 64
14:14:37.873010 IP 192.168.207.6 > 192.168.207.1: ICMP echo request, id 15631, seq 3, length 64
So as far as I can tell the tunnel is up, I just can't get traffic to hit the LAN side.


Edit...

Just did the same thing in reverse, pinging from my server down to the client while running tcpdump -i tun0 on the client, and I was able to see the ICMP replies and requests.
Last edited by digimars; 04-08-2010 at 01:22 PM.
 
Old 04-08-2010, 01:22 PM   #17
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
I do not no why but, sometime you wont be able to "ping" through tunnel.
But you definitely should traceroute the other side.

In your routing table on client there is a line:
10.10.202.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0

Can you change it to:
10.10.202.0 192.168.207.6 255.255.255.0 UG 0 0 0 tun0

And after restart network or reboot, after try to do
traceroute 10.10.202.2 from CLIENT computer, not from CLIENT network, please.

If your tunnel works you should see it.
Last edited by nimnull22; 04-08-2010 at 01:35 PM.
 
Old 04-08-2010, 01:44 PM   #18
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
OK! We're getting closer!

I made that change, and I can now ping 10.10.202.2 however, I can't hit 10.10.202.1 (which is the gateway of the OpenVPN server). This doesn't make sense, since the default gateway is 10.10.202.1 for that server.
 
Old 04-08-2010, 01:53 PM   #19
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Not so quickly, please.
First of all, I would like to ask you to do all tests from CLIENT computer only, and not from its LAN.
Please, do from CLIENT computer:
traceroute 10.10.202.2

Post please output here

Thanks
 
Old 04-08-2010, 01:58 PM   #20
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
I have only been doing these from the client computer, I don't have the client LAN hooked up yet since I wanted to get one piece working at a time.

From client:
Code:
[root@vpn02 ~]# traceroute 10.10.202.2
traceroute to 10.10.202.2 (10.10.202.2), 30 hops max, 40 byte packets
 1   (10.10.202.2)  2.481 ms  3.628 ms  3.608 ms
[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)  1.001 ms  43.114 ms  43.092 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *
 
Old 04-08-2010, 02:09 PM   #21
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
As I understand right, 10.10.202.2 is the IP address of eth1 of the OpenVPN server?

Do you remember, you have shown me script from OpenVPN, which configures iptables, I did not find anything about NAT table there, but your iptables-save has NAT postrouting rules.

Can you find where NAT can be changed on server?
Last edited by nimnull22; 04-08-2010 at 02:16 PM.
 
Old 04-08-2010, 02:28 PM   #22
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
Yep, 10.10.202.2 is eth1 of the OpenVPN server.

The nat part was in the original script, I just commented it out:
# Masquerade local subnet
# iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE
 
Old 04-08-2010, 02:54 PM   #23
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Ok. This is your NAT part of iptables on server:
# 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

I would like to ask you to REMOVE:
1. -A POSTROUTING -s 10.10.202.0/255.255.255.0 -o eth1 -j MASQUERADE
2. -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

When you made chances, please reload iptables and check if changes were applied.
 
Old 04-08-2010, 03:06 PM   #24
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
Ok, I finally figured out how to clean the POSTROUTING chain by using:

iptables -F -t nat

So here is my new output:
Code:
[root@botcovpn01 openvpn]# iptables-save
# Generated by iptables-save v1.3.5 on Thu Apr  8 16:04:32 2010
*nat
:PREROUTING ACCEPT [7623:422544]
:POSTROUTING ACCEPT [757:54282]
:OUTPUT ACCEPT [442:34633]
COMMIT
# Completed on Thu Apr  8 16:04:32 2010
# Generated by iptables-save v1.3.5 on Thu Apr  8 16:04:32 2010
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:2387]
: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 -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 16:04:32 2010
I can still ping 10.10.202.2 from the client, but not 10.10.202.1
 
Old 04-08-2010, 03:20 PM   #25
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Yes, that is good but you need some rules in NAT table.
We can add them later.

What I want you to do now is to add rule to NAT on the server:
Code:
iptables -t nat -A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth1 -j SNAT --to-source 10.10.202.2
After try to:
traceroute 10.10.202.1
 
Old 04-08-2010, 03:37 PM   #26
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
That worked!

I can ping from the client back to the server, now I need to set this up so that I can ping from the server down to 192.168.204.1 (the eth1 IP of the client machine).

So I assume that would be:
Code:
iptables -t nat -A POSTROUTING -s 192.168.207.0/255.255.255.0 -o eth1 -j SNAT --to-source 192.168.204.1
on the client machine, right?
Last edited by digimars; 04-08-2010 at 03:41 PM.
 
Old 04-08-2010, 03:55 PM   #27
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Wait please.

First, please post here output of:
traceroute 192.168.204.1
from server OpenVPN

Post also output of:
route -n
on the server.
 
Old 04-08-2010, 03:57 PM   #28
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
from server:

Code:
[root@vpn01 openvpn]# traceroute 192.168.204.1
traceroute to 192.168.204.1 (192.168.204.1), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
Code:
[root@vpn01 openvpn]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.207.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
X.X.X.112       0.0.0.0         255.255.255.248 U     0      0        0 eth0
10.10.202.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.204.0   192.168.207.2   255.255.255.0   UG    0      0        0 tun0
192.168.207.0   192.168.207.2   255.255.255.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         10.10.202.1     0.0.0.0         UG    0      0        0 eth1
Last edited by digimars; 04-08-2010 at 04:00 PM.
 
Old 04-08-2010, 04:10 PM   #29
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Lets make some changes. You have:
192.168.204.0 192.168.207.2 255.255.255.0 UG 0 0 0 tun0

Please, change it to:
192.168.204.0 192.168.207.5 255.255.255.0 UG 0 0 0 tun0

Also, remember, that any changes you have made through "route" or "ip" command are stored ONLY in memory, they are not permanent. So, after we finish (I hope) testing you need to write they to config. file on server and on client. Also this is true for iptables.
 
Old 04-08-2010, 04:15 PM   #30
digimars
Member
 
Registered: Nov 2005
Location: VA
Distribution: Fedora 12
Posts: 31

Original Poster
Rep: Reputation: 15
That didn't work out for me:

Code:
[root@vpn01 openvpn]# route del -net 192.168.204.0 netmask 255.255.255.0 gw 192.168.207.2
[root@vpn01 openvpn]# route add -net 192.168.204.0 netmask 255.255.255.0 gw 192.168.207.5
SIOCADDRT: Network is unreachable

I think the proper route is already there:

Code:
[root@vpn01 openvpn]# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:f1:bb:e9:96 brd ff:ff:ff:ff:ff:ff
    inet 10.10.202.2/24 brd 10.10.202.255 scope global eth1
    inet6 fe80::20c:f1ff:febb:e996/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:10:4b:07:03:01 brd ff:ff:ff:ff:ff:ff
    inet X.X.X.115/29 brd X.X.X.119 scope global eth0
    inet6 fe80::210:4bff:fe07:301/64 scope link 
       valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 192.168.207.1 peer 192.168.207.2/32 scope global tun0


[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
If I'm reading this right, 192.168.207.1 is the server, it's peer being 192.168.207.2 (the client), and in the routing table, we have 192.168.204.0/24 via 192.168.207.2 dev tun0.

So we have 192.168.207.1 -> 192.168.207.2 -> 192.168.204.0/24.

Is this just the firewall blocking it?
Last edited by digimars; 04-08-2010 at 04:37 PM.
 
  


Reply
Page 2 of 3 1 2 3

Tags
openvpn



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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Error When converting Routing OpenVPN to bridge mode openvpn danmartinj Linux - Software 0 11-06-2009 09:23 AM
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

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 11:27 AM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
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
Open Source Consulting | Domain Registration