[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Problem with multiple push "route..."


  • Subject: Re: [Openvpn-users] Problem with multiple push "route..."
  • From: "Thomas Heidemann" <Thomas.Heidemann@xxxxxxxxxxxxxxxx>
  • Date: Mon, 18 Sep 2006 18:38:15 +0200

Title: AW: [Openvpn-users] Problem with multiple push "route..."

Hi Erich,
sorry for not posting such a long time but I was out over the weekend.
Lets get's back to my problem....

In 2.0 it must be tcp-server or tcp-client. tcp alone is not sufficient.
lport defined the local porto which openvpn has to bind to. I didn't specify the remote port (of the client) becausethe server does not know, from where the connection comes. Also some http proxies might use other ports.

Here are some tcpdumps which show my problem after connection initialisation while I pinged the server (10.8.0.1):

Server (eth0):
18:24:37.108929 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 0
18:24:37.109462 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 52
18:24:37.175273 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
18:24:37.175375 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 350
18:24:37.201236 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
18:24:39.316469 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144 <-- Connection initialised here!
18:24:39.552296 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
18:24:40.024328 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
18:24:40.968406 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
18:24:42.856538 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
18:24:46.632802 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
18:24:54.185345 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144

Server (tun0):
- nothing -

Client (eth1):
18:24:37.103850 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 134
18:24:37.137511 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:24:37.138007 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 52
18:24:37.177338 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
18:24:37.205175 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 350
18:24:37.205299 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
18:24:39.344744 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144 <-- Connection initialised here!
18:24:39.580828 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:24:40.052614 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:24:40.996616 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:24:42.884875 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:24:46.661632 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:24:54.213854 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:25:07.367561 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:25:07.430113 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:25:07.430230 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 1448
18:25:07.430254 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 1442
18:25:07.432341 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 1440
18:25:07.465597 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:25:07.465713 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 8
18:25:07.489229 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:25:07.489314 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 1440
18:25:07.522441 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:25:07.522532 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 2
18:25:07.586203 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
18:25:09.319072 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
18:25:09.319173 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0

Client (tun0):
18:24:38.101454 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:24:39.045491 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:24:40.933656 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:24:43.156217 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 1, length 64
18:24:44.165874 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 2, length 64
18:24:44.709906 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:24:45.167015 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 3, length 64
18:24:46.166043 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 4, length 64
18:24:47.166131 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 5, length 64
18:24:48.166187 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 6, length 64
18:24:49.166262 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 7, length 64
18:24:50.166325 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 8, length 64
18:24:51.166404 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 9, length 64
18:24:52.166473 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 10, length 64
18:24:52.262445 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
18:24:53.166541 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 11, length 64
18:24:54.166620 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 12, length 64
18:24:55.166684 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 13, length 64
18:24:56.166763 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 14, length 64
18:24:57.166906 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 15, length 64
18:24:58.166900 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 16, length 64
tcpdump: pcap_loop: recvfrom: Network is down

Both clocks (server and client) are in sync!

Routing table of client after initialisation:
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.1        10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
145.253.90.32   10.8.0.9        255.255.255.224 UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.11.0    10.8.0.9        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
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.10    0.0.0.0         UG    0      0        0 eth1

So the routes are correct I think.

Greetings,
Thomas

-----Ursprüngliche Nachricht-----
Von: Erich Titl [mailto:erich.titl@xxxxxxxx]
Gesendet: Do 14.09.2006 23:06
An: Thomas Heidemann
Cc: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Betreff: Re: [Openvpn-users] Problem with multiple push "route..."

Thomas Heidemann wrote:
> Hi Erich,
>
> sorry for revealing the real network addresses. That's a global policy here but after talking to my boss...
> Please forget about all network addresses I talked about. Let's get to the real world.
> I omitted the nat box because I thought it doesn't matter (like in openvpn 1.6) and because some clients might not be in natted networks.
>
> Here the real diagram:
>
> Client --- 192.168.1.0/24 --- NAT box ==== Internet === Router --- 145.253.90.32/27 --- server
>                             85.216.23.103                 |
>                             (but can be dynamic)          |
>                                                       192.168.11.0/24
>
> The server has to push routes to 192.168.11.0/24 (via gateway "Router") and to 145.253.90.32/27 as well. There are other application servers which has to be reached.

Ooops this topology is quite different.

So to use the presented topology, the client packets at the server are
from 85.216.23.103 to something in the 145.253.90.32 network.

>
> Here the server config again:
> mode server
> tls-server
> proto tcp-server

I believe in 2.0 the protocol can just be tcp

> dev tun
> lport 443

What is lport?

> ca certs/ca.pem
> cert certs/server.crt
> key certs/server.key
> dh certs/dh2048.pem
> tls-auth certs/ta.key 0
> ifconfig 10.8.0.1 10.8.0.2
> ifconfig-pool 10.8.0.10 10.8.0.254
> route 10.8.0.0 255.255.0.0
> push "route 10.8.0.1"
> ifconfig-pool-persist ipp.txt
> push "route 192.168.11.0 255.255.255.0"
> push "route 145.253.90.32 255.255.255.224"
> client-config-dir /etc/openvpn/ccd
> keepalive 3 20
> comp-lzo
> persist-key
> persist-tun
> status /var/log/openvpn-status.log
> log /var/log/openvpn.log
> verb 5
> client-connect  "/etc/openvpn/scripts/client-up.sh"
> client-disconnect  "/etc/openvpn/scripts/client-down.sh"

looks mostly OK

>
> Extract of my server log file after initialisation:
> Thu Sep 14 22:13:05 2006 us=123623 85.216.23.103:2586 [client] Peer Connection Initiated with 85.216.23.103:2586
> Thu Sep 14 22:13:05 2006 us=137737 client/85.216.23.103:2586 MULTI: Learn: 10.8.0.10 -> client/85.216.23.103:2586
> Thu Sep 14 22:13:05 2006 us=137855 client/85.216.23.103:2586 MULTI: primary virtual IP for client/85.216.23.103:2586: 10.8.0.10
> RThu Sep 14 22:13:06 2006 us=214178 client/85.216.23.103:2586 PUSH: Received control message: 'PUSH_REQUEST'
> Thu Sep 14 22:13:06 2006 us=214321 client/85.216.23.103:2586 SENT CONTROL [client]: 'PUSH_REPLY,route 10.8.0.1,route 192.168.11.0 255.255.255.0,route 145.253.90.32 255.255.255.224,ping 3,ping-restart 20,ifconfig 10.8.0.10 10.8.0.9' (status=1)
> WWWWWWWWWWWWWWWWWWWWWWWWWW
> (I cut the connection because no ping went through)

Did you try to ping the 145.253.

> As you can see, the server sends packets but does not receive some.

Yes, but basically the packets look OK.

Did you make tcpdumps of this connection on eth0 on the server? If you
want you can save the dump with -w and analyse it using ethereal.
Correlate it to your logfiles.

>
> Extract from client log:
> Thu Sep 14 22:21:26 2006 us=344614 [server] Peer Connection Initiated with 145.253.90.49:443
> Thu Sep 14 22:21:27 2006 us=400212 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
> WRRRRThu Sep 14 22:21:27 2006 us=492880 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,route 192.168.11.0 255.255.255.0,route 145.253.90.32 255.255.255.224,ping 3,ping-restart 20,ifconfig 10.8.0.10 10.8.0.9'
> Thu Sep 14 22:21:27 2006 us=493023 OPTIONS IMPORT: timers and/or timeouts modified
> Thu Sep 14 22:21:27 2006 us=493048 OPTIONS IMPORT: --ifconfig/up options modified
> Thu Sep 14 22:21:27 2006 us=493069 OPTIONS IMPORT: route options modified
> Thu Sep 14 22:21:27 2006 us=494656 TUN/TAP device tun0 opened

good

> Thu Sep 14 22:21:27 2006 us=494764 TUN/TAP TX queue length set to 100
> Thu Sep 14 22:21:27 2006 us=494825 /sbin/ifconfig tun0 10.8.0.10 pointopoint 10.8.0.9 mtu 1500
> Thu Sep 14 22:21:27 2006 us=509825 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.9
> Thu Sep 14 22:21:27 2006 us=520439 /sbin/route add -net 192.168.11.0 netmask 255.255.255.0 gw 10.8.0.9
> Thu Sep 14 22:21:27 2006 us=530775 /sbin/route add -net 145.253.90.32 netmask 255.255.255.224 gw 10.8.0.9
> Thu Sep 14 22:21:27 2006 us=543085 Initialization Sequence Completed
> WWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrThu Sep 14 22:21:47 2006 us=893680 [server] Inactivity timeout (--ping-restart), restarting

This looks bad, it got the control message but then zilch.

>
> The WWrWr.... indicate that the client sends packets which never arrives. Remember, there is no firewall active!
>
> Hope this helps now.

It does a lot. Try to correlate with the tcpdump files. You should see a
tcp connection from 85.216.23.103 to your server 145.253.90.49 on eth0
and ICMP traffic from 10.8.0.10 to wherever you ping to on tun0.

Ooooh where is the default gateway of the 192.168.11.0 network? Did you
add the route to 192.168.1.0/24 to point to your OpenVPN server on your
router?

cheers

Erich



-------------------------------------------------------------------------
Get stuff done quickly with pre-integrated technology to make your job easier
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users