LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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
  Search this Thread
Old 02-21-2008, 06:41 AM   #1
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Rep: Reputation: 16
Trying to route via OpenVPN client


Hello, *

I have a problem.

I am trying to connect two networks, 10.x.y.z and 192.168.87.t via a VPN tunnel.
The tunnel itself works, and I can route via the server, but not via the client.

The (in my opinion, of course) relevant machines are:
A 192.168.87.6 the machine from which I try to control everything
B 192.168.87.5 the VPN client/designated router (this is where I seem to have a problem)
C 10.0.0.21 the VPN server, and router (which works)

When I try to PING from Machine A to Machine C, I get no reply.

Using tcpdump -i tun0 icmp,
these come from Machine A, tcpdump on machine B, do not arrive at machine C:

11:33:07.263612 IP 192.168.87.6 > 10.0.0.21: ICMP echo request, id 42802, seq 7, length 64
11:33:08.264026 IP 192.168.87.6 > 10.0.0.21: ICMP echo request, id 42802, seq 8, length 64
11:33:09.263407 IP 192.168.87.6 > 10.0.0.21: ICMP echo request, id 42802, seq 9, length 64
11:33:10.350762 IP 192.168.87.6 > 10.0.0.21: ICMP echo request, id 42802, seq 10, length 64

Of course I also used tcpdump at machine C, to verify, and I never see anything from
icmp appear on tun0.

Next I start ping from machine B: these arrive at machine C, and get replies:

11:33:51.049617 IP 192.168.101.10 > 10.0.0.21: ICMP echo request, id 27714, seq 1, length 64
11:33:51.135377 IP 10.0.0.21 > 192.168.101.10: ICMP echo reply, id 27714, seq 1, length 64
11:33:52.050230 IP 192.168.101.10 > 10.0.0.21: ICMP echo request, id 27714, seq 2, length 64
11:33:52.133727 IP 10.0.0.21 > 192.168.101.10: ICMP echo reply, id 27714, seq 2, length 64
11:33:53.050244 IP 192.168.101.10 > 10.0.0.21: ICMP echo request, id 27714, seq 3, length 64
11:33:53.133586 IP 10.0.0.21 > 192.168.101.10: ICMP echo reply, id 27714, seq 3, length 64
11:33:54.050243 IP 192.168.101.10 > 10.0.0.21: ICMP echo request, id 27714, seq 4, length 64
11:33:54.133149 IP 10.0.0.21 > 192.168.101.10: ICMP echo reply, id 27714, seq 4, length 64

My routing table on Machine A:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.0.116.140 * 255.255.255.255 UH 0 0 0 ppp0
localnet * 255.255.255.0 U 0 0 0 eth0
10.0.0.0 Penti 255.255.0.0 UG 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default * 0.0.0.0 U 0 0 0 ppp0
#
so indeed, packets for 10.0.0.21 will go to "Penti", which is Machine B.

On Machine B, I have a routing table:
# route
Kernel IP routing table
Destination * * Gateway * * * * Genmask * * * * Flags Metric Ref Use Iface
192.168.101.9 * * * * * * * * * 255.255.255.255 UH * *0 * * *0 * 0 tun0
192.168.101.1 * 192.168.101.9 * 255.255.255.255 UGH * 0 * * *0 * 0 tun0
192.168.101.0 * 192.168.101.9 * 255.255.255.0 * UG * *0 * * *0 * 0 tun0
192.168.87.0 * ** * * * * * * * 255.255.255.0 * U * * 0 * * *0 * 0 eth0
link-local * * ** * * * * * * * 255.255.0.0 * * U * * 1000 * 0 * 0 eth0
10.0.0.0 * * * *192.168.101.9 * 255.0.0.0 * * * UG * *0 * * *0 * 0 tun0
default * * * * 192.168.87.6 * *0.0.0.0 * * * * UG * *100 * *0 * 0 eth0

so everything entering for 10.x.y.z should go to 192.168.101.9, and via tun0 to machine C.
And indeed, as the above example shows, it does come out on tun0, but then it only seems to arrive at the other end when originating on machine B, but not when routed from Machine A.

Of course:

root@Penti:/home/administrator# cat /proc/sys/net/ipv4/ip_forward
1

and the firewall is empty:

root@Penti:/home/administrator# iptables -L
Chain INPUT (policy ACCEPT)
target * * prot opt source * * * * * * * destination * * * *

Chain FORWARD (policy ACCEPT)
target * * prot opt source * * * * * * * destination * * * *

Chain OUTPUT (policy ACCEPT)
target * * prot opt source * * * * * * * destination * * * *

Am I missing something?
 
Old 02-21-2008, 06:46 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
is there a route on C to 192.168.87.0/24? can you see the echo requests actually hitting C?
 
Old 02-21-2008, 07:11 AM   #3
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
My routing table on C is:

admin@openvpn:~$ route
Kernel IP routeing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.101.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.101.0 192.168.101.2 255.255.255.0 UG 0 0 0 tun0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
default SpeedTouch.lan 0.0.0.0 UG 0 0 0 eth0

Where SpeedTouch.lan is the Internet interface. Every reply should go there.

I do not think that is the problem; ping from Machine B arrives at Machine C, but the pings from Machine A are not even seen to enter!
And if they entered, they would be replied to via tun0
 
Old 02-21-2008, 07:32 AM   #4
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
every reply should not go to eth0, that's the point you have a tunnel in the first place no?

so there you clearly have a route to 192.168.101.0 but not 192.168.87.0
 
Old 02-21-2008, 07:52 AM   #5
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
I do have a tunnel, yes. And, as I said already, PING from Machine B goes on, although it has the "from" address 192.168.101.10, which is in the routing table. Good point, probably PINGs from 192.167.87.6 would not get a reply anyway, even if they did get through. I will correct this, but I am afraid that, as long as the ICMP requests do not even arrive (according to tcpdump on Machine C), there will not be a reply anyway...
 
Old 02-21-2008, 08:12 AM   #6
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
i've told you twice now exactly what the problem is... are you not familiar with IP routing?
 
Old 02-21-2008, 08:20 AM   #7
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
No, I think you haven't, but perhaps I misunderstand ;-(. You point out that the replies would never arrive (I agree, thanks), but the replies are never generated at all, since the requests do not get through.
I made the correction you suggested by adding a route entry, my routing table (on machine C) is now:

Kernel IP routeing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.87.6 192.168.101.2 255.255.255.255 UGH 0 0 0 tun0
192.168.101.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.101.0 * 255.255.255.0 U 0 0 0 tun0
192.168.101.0 192.168.101.2 255.255.255.0 UG 0 0 0 tun0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
default SpeedTouch.lan 0.0.0.0 UG 0 0 0 eth0
admin@openvpn:~$
so I presume that now alle replies should go to tun0. Well, there are still no replies, so the effect is still minimal. Moreover, I tried ping 192.168.87.6 from Machine C, which should go to tun0, but it still never arrives at the other end, just the same problem as from A to C, I presume.

The problem really seems to be that not everything that goes out on tun0 pops up at the other end... but some things do... and I still do not see why...
 
Old 02-21-2008, 09:03 AM   #8
rossonieri#1
Member
 
Registered: Jun 2007
Posts: 359

Rep: Reputation: 34
hi jjge,

Quote:
The (in my opinion, of course) relevant machines are:
A 192.168.87.6 the machine from which I try to control everything
B 192.168.87.5 the VPN client/designated router (this is where I seem to have a problem)
C 10.0.0.21 the VPN server, and router (which works)
hmm.. ok lets make this slowly.
what ip address does B has for the tunnel?
does A & B has the route to remote 10.0.0.0 network?
ok - if you put DHCP for B's request then probably you should have B assign 10.0.0.x ip right?
but how about A? does it have the route to 10.0.0.0 network?

and viceversa for C.

try ping C from A and listen on C - does it have a request? if not then there is something wrong on A or B.

if yes - then there is something wrong on C.

you must have a bidirectional route to establish a commmunication.

CMIIW

HTH.
 
Old 02-21-2008, 09:36 AM   #9
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
> what ip address does B has for the tunnel?

Here are the outputs of ifconfig:

On machine 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.101.10 P-t-P:192.168.101.9 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:168 errors:0 dropped:0 overruns:0 frame:0
TX packets:621 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:26632 (26.0 KB) TX bytes:53020 (51.7 KB)

On machine C, tun0 is:

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.101.1 P-t-P:192.168.101.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:236 errors:0 dropped:0 overruns:0 frame:0
TX packets:248 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:20904 (20.4 KiB) TX bytes:30764 (30.0 KiB)

> does A & B has the route to remote 10.0.0.0 network?

I gave the route tables already-- 10.x.y.z. on A goes to B (gateway); B goes to 192.168.101.9 via tun0. I can verify that this takes place. The reverse route was incomplete, as acid_kewpie pointed out (I corrected it); however, I do not even see the requests arriving at C.

> Then
> ok - if you put DHCP for B's request then probably you should have B > assign 10.0.0.x ip right?

I am not using DHCP-- all addresses and routes are static.

> but how about A? does it have the route to 10.0.0.0 network?

Yes, via 192.168.87.5 (Penti)

> and viceversa for C.

> try ping C from A and listen on C - does it have a request?

No. The last I see is on tun0 on B. There it goes "out", according to tcpdump, but it never arrives at C.

> if not then there is something wrong on A or B. Something on B, I guess, ... but what? Remember, ping from A gets until tun0 on B, but ping from B is seen on C, and the replies go back as well.

> if yes - then there is something wrong on C.

Well there _was_ something wrong on C, so the replies would not have made it anyway. But the problem appears to be earlier... icmp request gong to B: tun0, but not turning up on C: tun0

> you must have a bidirectional route to establish a commmunication.
 
Old 02-21-2008, 10:25 AM   #10
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
AFAIK, in order for traffic to reach the VPN peer then it must have agreed what traffic is allowed into it, so you'll need to configure the "server" side of the VPN config to expect traffic from them in the first place. it's not as transparent as general routing links.

Last edited by acid_kewpie; 02-21-2008 at 10:26 AM.
 
Old 02-21-2008, 10:32 AM   #11
rossonieri#1
Member
 
Registered: Jun 2007
Posts: 359

Rep: Reputation: 34
hi,

please do comment my drawing here :

A ---(192.168.87.0)---B--(tun0 : 192.168.101.0)----C----(10.0.0.0)

is it correct?
so C is a router, and B also.

if it so then why you put another ip assign to C? which is different then what B has as p2p tunnel to C.

i think B as 101.10 and C as 101.9 is enough,
see your last post that you have different ip address for tunn0 on B and another on C - this will make an asymetric route.

and just add the correct route :
from C to A via 101.10 (B),
from A to C via 87.7(B)
from A to 10.0.0.0 also via 87.7 (B)
from B to 10.0.0.0 via 101.9 (C)
from 10.0.0.0 via 0.21 (C)
B to C is directly connected via tunnel so no need to add another route.

and, put your default route in a higher metric than the static tunnel0.


CMIIW.

HTH.

Last edited by rossonieri#1; 02-21-2008 at 10:34 AM.
 
Old 02-21-2008, 11:14 AM   #12
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
> please do comment my drawing here :
> A ---(192.168.87.0)---B--(tun0 : 192.168.101.0)----C----(10.0.0.0)
> is it correct?

Not quite, I think. More like this:

A(eth0:192.168.87.6)--B(eth0:192.168.87.5)(tun0:192.168.101.10)-->
--> C(tun0:192.168.101.9)(eth0: 10.0.0.21)
and in the reverse direction
C(tun0: 192.168.101.1)(eth0:10.0.0.21) --> B(tun0:192.168.101.2)

> so C is a router, and B also.

That is correct,and intended.

> if it so then why you put another ip assign to C? which is different then what B has as p2p tunnel to C.

Well, the 192.168.87 and 10.x.y.z addresses are given (in two existing networks). I do not want to change them.

The 192.168.101.x addresses are given in the server config file, and according to the documentation, they are treated as a pool.

My server.conf is:

port 1194
proto tcp-server
dev tun
tls-server
mode server
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 192.168.101.0 255.255.255.0
ifconfig-pool-persist ipp.txt
route 192.168.87.6 255.255.255.255
tun-mtu 1500
mssfix 1450
keepalive 10 120
route-up "route delete -net 192.168.101.0/24"
route-up "route add -net 192.168.101.0/24 tun0"
push "route 10.0.0.0 255.0.0.0"
push "route 192.168.101.1"
push "dhcp-option DNS 10.0.0.138"
client-to-client
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
management localhost 7505



and my client.conf is:

client
dev tun
proto tcp
remote aa.bb.cc.dd 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert jjge.crt
key jjge.key
comp-lzo
verb 3
 
Old 02-21-2008, 11:34 AM   #13
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by acid_kewpie View Post
AFAIK, in order for traffic to reach the VPN peer then it must have agreed what traffic is allowed into it, so you'll need to configure the "server" side of the VPN config to expect traffic from them in the first place. it's not as transparent as general routing links.
That could be true, but even then, ping from Machine B arrives, and ping from machine A does not... and how should I change this state of affairs? So far, I have not yet found anything in the documentation that relates to this problem.
 
Old 02-21-2008, 12:03 PM   #14
rossonieri#1
Member
 
Registered: Jun 2007
Posts: 359

Rep: Reputation: 34
ok - much clearer now.

Quote:
Not quite, I think. More like this:

A(eth0:192.168.87.6)--B(eth0:192.168.87.5)(tun0:192.168.101.10)-->
--> C(tun0:192.168.101.9)(eth0: 10.0.0.21)
and in the reverse direction
C(tun0: 192.168.101.1)(eth0:10.0.0.21) --> B(tun0:192.168.101.2)

> so C is a router, and B also.

That is correct,and intended.
C :
Kernel IP routeing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.87.6 192.168.101.2 255.255.255.255 UGH 0 0 0 tun0
192.168.101.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.101.0 * 255.255.255.0 U 0 0 0 tun0
192.168.101.0 192.168.101.2 255.255.255.0 UG 0 0 0 tun0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
default SpeedTouch.lan 0.0.0.0 UG 0 0 0 eth0

B :
On Machine B, I have a routing table:
# route
Kernel IP routing table
Destination * * Gateway * * * * Genmask * * * * Flags Metric Ref Use Iface
192.168.101.9 * * * * * * * * * 255.255.255.255 UH * *0 * * *0 * 0 tun0
192.168.101.1 * 192.168.101.9 * 255.255.255.255 UGH * 0 * * *0 * 0 tun0
192.168.101.0 * 192.168.101.9 * 255.255.255.0 * UG * *0 * * *0 * 0 tun0
192.168.87.0 * ** * * * * * * * 255.255.255.0 * U * * 0 * * *0 * 0 eth0
link-local * * ** * * * * * * * 255.255.0.0 * * U * * 1000 * 0 * 0 eth0
10.0.0.0 * * * *192.168.101.9 * 255.0.0.0 * * * UG * *0 * * *0 * 0 tun0
default * * * * 192.168.87.6 * *0.0.0.0 * * * * UG * *100 * *0 * 0 eth0

there - from your initial physical (even before tunnel gets up - you must have an established routing too) there is no way i guess that B and C will talk to each other.
B's gateway back to A? and C dont have one?

there is no way you can sniff traffic from non-networked router.

please do correct the route :
B should have 87.5 (itself) as gateway
C - instead of eth0 - put itself as the gateway 10.0.0.21

see the result.

HTH.
 
Old 02-21-2008, 12:24 PM   #15
jjge
Member
 
Registered: Jun 2003
Location: Kalkar, Germany
Distribution: Slackware
Posts: 108

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by rossonieri#1 View Post
there - from your initial physical (even before tunnel gets up - you must have an established routing too) there is no way i guess that B and C will talk to each other.
B's gateway back to A?
Yes, B has A as a router, and as a firewall, A also maintains the ADSL connection, and the packets on the tunnel interface (tun0 to tun0) do flow to their destination via A. Strange though it may seem (and I might consider rearrangement later), it works quite well, except for this routing issue.
And B and C do talk to one another. If I ping from B, C replies, via the tunnel through A. And C acts as a router for the network behind it as well; I can (and do) manage all servers in the 10.x.y.z network via ssh or vnc, via the VPN.
Quote:
And C dont have one?
please do correct the route :
B should have 87.5 (itself) as gateway
C - instead of eth0 - put itself as the gateway 10.0.0.21
I am afraid that if I follow your suggestion, there is no way anymore to contact C, and I have to drive to the site to restore the connection. The SpeedTouch.lan is actually the ADSL modem/firewall; it is the only connection via which I can talk to the network.

And even then, the server still routes perfectly inside the 10.x.y.z network. All I cannot do is routing from 192.168.87.6 via B, and I still do not see, why not.
 
  


Reply


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



Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenVPN client has not default gateway when connect to OpenVPN server sailershen Linux - Security 3 03-04-2010 02:20 AM
OpenVPN route issues, all traffic through VPN tunnel stuartornum Linux - Server 4 03-05-2007 03:07 AM
OpenVPN and default route ziobudda Linux - Networking 0 09-13-2006 10:04 AM
Openvpn client to client routing question soup Linux - Networking 0 02-16-2006 11:13 AM
OpenVPN client cannot route to LAN TheAmazingSteve Linux - Networking 1 09-29-2005 03:40 PM

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

All times are GMT -5. The time now is 12:22 PM.

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