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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm sorry I do not understand what this sentence means:
Quote:
It's good to see you've ironed out the kinks Erik.
I put a "pull" in the "/etc/openvpn/client.conf" file:
Code:
client
;dev tap
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote W1.X1.Y1.Z1 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
;tls-auth ta.key 1
;cipher x
comp-lzo
verb 3
;mute 20
pull
I didn't change "/etc/openvpn/server.conf".
Quote:
Upgrading your client is never a bad thing and should get rid of your error message, but your core problem is one of routing.
No error message anymore in "/var/log/syslog" on client side.
And yes my problem is probably a routing one!
Quote:
Just out of curiosity how long does that take with Debian? I've never used it.
Well, you know, it really depends on:
- the number of times you have already done an installation,
- the number of web services and other things you want to make available on your server,
- luck because sometimes you are not stuck and sometimes you are (like me presently ).
I put a DHCP server, a DNS server and a SAMBA server.
I did it very quickly because that was the previous time I got stuck :/
That time everything was neatly prepared.
For example last time I had a problem with my keyboard not switching to azerty...
Erik
Quote:
But that's probably because my server is older than the client.
All right, I didn't pay attention to that!
And unfortunately :
After a fresh install as I said, the pinging problem remains.
(The OpenVPN server 192.168.0.4 cannot ping the OpenVPN client 192.168.2.4).
I tried something:
On the server:
Code:
192.168.0.4 # tcpdump -vvv -i eth0 -n port 1194
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:11:14.356626 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 81) W2.X2.Y2.Z2.1194 > 192.168.0.4.1194: [udp sum ok] UDP, length 53
17:11:17.538064 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 81) 192.168.0.4.1194 > W2.X2.Y2.Z2.1194: [udp sum ok] UDP, length 53
On the client:
Code:
192.168.2.4 # tcpdump -vvv -i eth0 -n port 1194
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:11:06.087426 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 81) W1.X1.Y1.Z1.1194 > 192.168.2.4.1194: [udp sum ok] UDP, length 53
17:11:12.245448 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 81) 192.168.2.4.1194 > W1.X1.Y1.Z1.1194: [bad udp cksum 4852!] UDP, length 53
(W1.X1.Y1.Z1: public IP of the router on the server side.
W2.X2.Y2.Z2: public IP of the router on the client side.)
I don't know what to think about that...
All the best,
--
Léa
Last edited by leamassiot; 08-14-2009 at 10:40 AM.
I was wondering, Erik, if you could be so very nice to give me the exact "route add" commands you executed:
- on a machine which is not the OpenVPN client but which is on the same subnetwork as the OpenVPN client,
- on a machine which is not the OpenVPN server but which is on the same subnetwork as the OpenVPN server.
You said in post #24:
Quote:
my VPN-server can't ping anyone on the client-side
Can your VPN-server ping your VPN-client now?
Quote:
Bit of a long explanation that could be difficult to follow. But the routes seems to be functioning properly
and my VPN-server don't need to contact the client side so I'll leave it like it is for the time being.
Does it mean that your VPN-server doesn't ping your VPN-client?
Quote:
Again, from post #24:
traceroute from the VPN-server stops at the tun-device.
If it's not too much asking, could you show me the output of your traceroute command?
Because, for me, my traceroute (on the client) is quite straightforward:
Code:
192.168.2.4 # traceroute 192.168.0.4
traceroute to 192.168.0.4 (192.168.0.4), 30 hops max, 40 byte packets
1 192.168.0.4 (192.168.0.4) 117.788 ms 121.847 ms 123.598 ms
192.168.2.4 #
Thank you for helping and all the best,
--
Léa
Last edited by leamassiot; 08-14-2009 at 10:40 AM.
I was wondering, Erik, if you could be so very nice to give me the exact "route add" commands you executed:
- on a machine which is not the OpenVPN client but which is on the same subnetwork as the OpenVPN client,
I added 2 routes; 1 for the server-side subnet through the VPN-client; and 1 for the OpenVPN subnet through the VPN-client.
Like this:
route add -net 192.168.0.0/24 gw 192.168.2.4
route add -net 10.8.0.0/24 gw 192.168.2.4
Quote:
- on a machine which is not the OpenVPN server but which is on the same subnetwork as the OpenVPN server.
On this side I have a Linux FW/Router and I put in the following route:
route add -net 192.168.2.0/24 gw 192.168.0.4
route add -net 10.8.0.0/24 gw 192.168.0.4
Quote:
Can your VPN-server ping your VPN-client now?
Does it mean that your VPN-server doesn't ping your VPN-client?
It didn't but it does now.
The traceroute for both my server and client is straightforward. Clients on either side will show to go through the tun-device IP. You can also use the tracepath command to follow the packets route. It should show you where the packet stops.
Just checking, but I'm going from the following assumptions.
Both server and client are now running openvpn 2.1 which is currently at release candidate rc19.
You do not have a firewall on either machine.
cat /proc/sys/net/ipv4/ip_forward returns 1 on both machines
You can ping either machine from the other using the 10.8.0.x address.
You can ping the server and any machine you want in the 192.168.0.x address space from the client.
You cannot ping the client or any machines in the 192.168.2.x address space from the server.
You are where the server is.
Can you ssh into the client machine using the 10.8.0.6 address?
Can you ssh into the client machine using the 192.168.2.4 address?
Have you tried traceroute from each end to see where the packets are dropping?
Other than those rather obvious things, I'm at a loss as to what's next. This is confusing.
I added the same routes as you did.
192.168.0.8 can ping 10.8.0.6 and 10.8.0.1 but not 192.168.2.4 nor 192.168.2.202.
192.168.2.202 can ping 10.8.0.6 and 10.8.0.1 but not 192.168.0.4 not 192.168.0.8.
192.168.0.4 # tracepath 192.168.2.4
1: 10.8.0.1 (10.8.0.1) 0.211ms pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
31: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
Mike
>> So everything looks ok, it's just not working.
Yes .
>> Just checking, but I'm going from the following assumptions.
>> Both server and client are now running openvpn 2.1
Yes.
>> You do not have a firewall on either machine.
Yes.
>> cat /proc/sys/net/ipv4/ip_forward returns 1 on both machines
Yes.
>> You can ping either machine from the other using the 10.8.0.x address.
Yes.
>> You can ping the server and any machine you want in the 192.168.0.x address space from the client.
Yes.
>> You cannot ping the client or any machines in the 192.168.2.x address space from the server.
Yes.
>> You are where the server is.
No.
I am where the client is.
>> Can you ssh into the client machine using the 10.8.0.6 address?
Yes I can.
Same result as "ssh root@W2.X2.Y2.Z2".
W2.X2.Y2.Z2 redirects what is receives on its port 22 to 192.168.2.4.
>> Can you ssh into the client machine using the 192.168.2.4 address?
No.
>> Have you tried traceroute from each end to see where the packets are dropping?
On one end yes, see post #36.
On the other end, no because I am not in Paris and the last time I did it I had to reboot my router :/
something I wont be able to do this time...
>> This is confusing.
Yes and maybe a bit more than that .
What is the response from your vpn-client if you start it manually? You should be able to see what routes your client defines during connection. Make sure you don't have routes to your server network 192.168.0.0/24 nor the vpn-network 10.8.0.0/24 on your client before you start the VPN-client. If they are present you'll get an error during creation. If not they should be created when the client connects to the server.
What is the response from your vpn-client if you start it manually?
You should be able to see what routes your client defines during connection.
I sent the results of the "route -n" commands on both the server and the client (cf. post #34).
Don't you have the same routes?
Here are the log lines produced in "/var/log/syslog" when executing "/etc/init.d/openvpn start"
on the server first and then on the client.
From "/var/log/syslog" on 192.168.0.4 (OpenVPN server):
Code:
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: OpenVPN 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008
Be aware that this might create routing conflicts if you connect to the VPN server from
public locations such as internet cafes that use the same subnet.r 192.168.1.x.
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: Diffie-Hellman initialized with 1024 bit key
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: ROUTE default_gateway=192.168.0.1
Aug 12 16:04:53 192.168.0.4 kernel: [145259.812080] tun0: Disabled Privacy Extensions
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: TUN/TAP device tun0 opened
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: TUN/TAP TX queue length set to 100
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.8.0.2
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Aug 12 16:04:53 192.168.0.4 ovpn-server[11459]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: Socket Buffers: R=[111616->131072] S=[111616->131072]
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: UDPv4 link local (bound): [undef]:1194
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: UDPv4 link remote: [undef]
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: MULTI: multi_init called, r=256 v=256
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: IFCONFIG POOL: base=10.8.0.4 size=62
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: IFCONFIG POOL LIST
Aug 12 16:04:53 192.168.0.4 ovpn-server[11467]: Initialization Sequence Completed
From "/var/log/syslog" on 192.168.2.4 (OpenVPN client):
Code:
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: OpenVPN 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.
OpenVPN 2.0-beta 16 and earlier used 5000 as the default port.
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: LZO compression initialized
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: Local Options hash (VER=V4): '41690919'
Aug 12 16:10:36 192.160.2.4 ovpn-client[12908]: Expected Remote Options hash (VER=V4): '530fdded'
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Socket Buffers: R=[111616->131072] S=[111616->131072]
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: UDPv4 link local (bound): [undef]:1194
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: UDPv4 link remote: W1.X1.Y1.Z1:1194
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: TLS: Initial packet from W1.X1.Y1.Z1:1194, sid=cafc8702 256a467e
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: VERIFY OK: depth=1, /C=FR/ST=IF/L=****/O=****/CN=****/emailAddress=****
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: VERIFY OK: nsCertType=SERVER
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: VERIFY OK: depth=0, /C=FR/ST=IF/L=****/O=****/CN=****/emailAddress=****
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: [192.168.0.4] Peer Connection Initiated with W1.X1.Y1.Z1:1194
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: SENT CONTROL [192.168.0.4]: 'PUSH_REQUEST' (status=1)
Aug 12 16:10:36 192.160.2.4 kernel: [175736.376252] tun0: Disabled Privacy Extensions
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0 10.8.0.5,route 10.8.0.0 255.255.255.0,
topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: OPTIONS IMPORT: route options modified
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: ROUTE default_gateway=192.168.2.1
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: TUN/TAP device tun0 opened
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: TUN/TAP TX queue length set to 100
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.5
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5
Aug 12 16:10:36 192.160.2.4 ovpn-client[12910]: Initialization Sequence Completed
Quote:
If they are present you'll get an error during creation. If not they should be created when the client connects to the server.
As far as I can see, there are no errors and the routes are actually created when the client connects to the server.
Dear friends,
I am sorry I didn't solve my problem this time but I have to stop working on that for the moment.
I thank Mike and Erik for their help and their availability.
Apart from the fact that it was nice to have people helping me I discovered new tools like "wireshark" and "tracepath".
If suddendly you realize: "oh yes this is where Léa has forgotten something or made a mistake!"... please tell
me...
Thank you again and see you soon,
--
Léa
Last edited by leamassiot; 08-14-2009 at 10:42 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
).
:
,
