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

Re: [Openvpn-users] Configuration problems


  • Subject: Re: [Openvpn-users] Configuration problems
  • From: Koen Vermeer <koen@xxxxxxxxxx>
  • Date: Fri, 21 Dec 2007 15:50:02 +0100

Hi Jan Just,

The 65.55.200.221 address doesn't ring a bell, so I have to idea what it
may be. I just tried again, and the route is now a bit different. Maybe
due to all the fiddling, Windows got confused. Anyway, the new route
print ('after') shows:

Active Routes:
Network Destination        Netmask          Gateway       Interface
Metric
          0.0.0.0          0.0.0.0    172.17.145.20   172.17.145.70
1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1
1
     172.17.145.0    255.255.255.0    172.17.145.70   172.17.145.70
30
    172.17.145.70  255.255.255.255        127.0.0.1       127.0.0.1
30
   172.17.255.255  255.255.255.255    172.17.145.70   172.17.145.70
30
    192.87.167.62  255.255.255.255      192.168.1.1    192.168.1.27
1
      192.168.1.0    255.255.255.0     192.168.1.27    192.168.1.27
10
     192.168.1.27  255.255.255.255        127.0.0.1       127.0.0.1
10
    192.168.1.255  255.255.255.255     192.168.1.27    192.168.1.27
10
        224.0.0.0        240.0.0.0    172.17.145.70   172.17.145.70
30
        224.0.0.0        240.0.0.0     192.168.1.27    192.168.1.27
10
  255.255.255.255  255.255.255.255    172.17.145.70   172.17.145.70
1
  255.255.255.255  255.255.255.255     192.168.1.27    192.168.1.27
1
Default Gateway:     172.17.145.20

tracert -d 192.87.167.62 shows 192.168.1.1 (my router), 192.168.2.1 (my
ADSL modem) and then on to the versatel network. I enabled ping on
192.87.167.62, and tracert went all the way to 192.87.167.62. So that
route seems to work fine (I guess).

tracert -d 172.17.145.20, however, only results in time outs. When I
ping from the internal 172.17.145.0 network, .20 replies just fine.

Without the "push redirect-gateway", 'route print' shows:

Active Routes:
Network Destination        Netmask          Gateway       Interface
Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.27
10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1
1
     172.17.145.0    255.255.255.0    172.17.145.70   172.17.145.70
30
    172.17.145.70  255.255.255.255        127.0.0.1       127.0.0.1
30
   172.17.255.255  255.255.255.255    172.17.145.70   172.17.145.70
30
    192.87.167.62  255.255.255.255      192.168.1.1    192.168.1.27
1
      192.168.1.0    255.255.255.0     192.168.1.27    192.168.1.27
10
     192.168.1.27  255.255.255.255        127.0.0.1       127.0.0.1
10
    192.168.1.255  255.255.255.255     192.168.1.27    192.168.1.27
10
        224.0.0.0        240.0.0.0    172.17.145.70   172.17.145.70
30
        224.0.0.0        240.0.0.0     192.168.1.27    192.168.1.27
10
  255.255.255.255  255.255.255.255    172.17.145.70   172.17.145.70
1
  255.255.255.255  255.255.255.255     192.168.1.27    192.168.1.27
1
Default Gateway:       192.168.1.1

ping 172.17.145.20 results in timeouts.

So, I guess I cannot reach 172.17.145.20. I still don't know how the
routing is supposed to work, so I have no idea where to look for
problems. Could you enlighten me on the routing stuff? I mean, suppose I
want to reach a hypothetical address of 123.123.123.123 from
172.17.145.70. It would have to go to 192.168.1.1 first, then
192.168.2.1, then over the internet to 192.87.167.62, then through the
NAT to 172.17.145.20, and then again through the NAT to 123.123.123.123.
Who should do what (Windows, OpenVPN client, OpenVPN server, etc.) is
beyond me...

Thanks!

Koen


On Tue, 2007-12-18 at 10:19 +0100, Jan Just Keijser wrote:
> Hi Koen,
> 
> your "after" routes show one funny thing but apart from that they seem 
> fine.
> 
> 65.55.200.221  255.255.255.255      192.168.1.1    192.168.1.27 1
> 
> which host is this?
> 
> also, can you try to traceroute to the openvpn server after starting 
> openvpn, e.g.
>   tracert -d 192.87.167.62
> and see which route is selected? your "After" routing table suggests 
> that it should go thru 192.168.1.1
> And, as a final test, what happens if you try it *without* the "push 
> redirect-gateway" ? can you then reach the openvpn network (e.g. try
>   ping 172.17.145.20
> )
> 
> cheers,
> 
> JJK
> 
> Koen Vermeer wrote:
> > Hi Jan Just,
> >
> > Thanks for the reply. Unfortunately, it didn't seem to solve my problem;
> > routing probably still doesn't work. I've got the results of 'route
> > print' before and after connecting. Apologies for the layout... Before:
> >
> > Active Routes:
> > Network Destination        Netmask          Gateway       Interface
> > Metric
> >           0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.27
> > 1
> >         127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1
> > 1
> >       192.168.1.0    255.255.255.0     192.168.1.27    192.168.1.27
> > 10
> >      192.168.1.27  255.255.255.255        127.0.0.1       127.0.0.1
> > 10
> >     192.168.1.255  255.255.255.255     192.168.1.27    192.168.1.27
> > 10
> >         224.0.0.0        240.0.0.0     192.168.1.27    192.168.1.27
> > 10
> >   255.255.255.255  255.255.255.255     192.168.1.27    192.168.1.27
> > 1
> >   255.255.255.255  255.255.255.255     192.168.1.27               3
> > 1
> > Default Gateway:       192.168.1.1
> >
> > After:
> >
> > Active Routes:
> > Network Destination        Netmask          Gateway       Interface
> > Metric
> >           0.0.0.0        128.0.0.0    172.17.145.20   172.17.145.70
> > 1
> >           0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.27
> > 1
> >     65.55.200.221  255.255.255.255      192.168.1.1    192.168.1.27
> > 1
> >         127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1
> > 1
> >         128.0.0.0        128.0.0.0    172.17.145.20   172.17.145.70
> > 1
> >      172.17.145.0    255.255.255.0    172.17.145.70   172.17.145.70
> > 30
> >     172.17.145.70  255.255.255.255        127.0.0.1       127.0.0.1
> > 30
> >    172.17.255.255  255.255.255.255    172.17.145.70   172.17.145.70
> > 30
> >     192.87.167.62  255.255.255.255      192.168.1.1    192.168.1.27
> > 1
> >       192.168.1.0    255.255.255.0     192.168.1.27    192.168.1.27
> > 10
> >      192.168.1.27  255.255.255.255        127.0.0.1       127.0.0.1
> > 10
> >     192.168.1.255  255.255.255.255     192.168.1.27    192.168.1.27
> > 10
> >         224.0.0.0        240.0.0.0    172.17.145.70   172.17.145.70
> > 30
> >         224.0.0.0        240.0.0.0     192.168.1.27    192.168.1.27
> > 10
> >   255.255.255.255  255.255.255.255    172.17.145.70   172.17.145.70
> > 1
> >   255.255.255.255  255.255.255.255     192.168.1.27    192.168.1.27
> > 1
> > Default Gateway:     172.17.145.20
> >
> > I'm not that familiair with these routes, so maybe I'm misinterpreting
> > them. But let's say I want to connect to 72.14.215.104. I guess this
> > simply goes to the default gateway of 172.17.145.20. I'm not sure if
> > this gets resolved any further, or that routing stops now. In the latter
> > case, I guess it never reaches 172.17.145.20, which is on a NAT with an
> > outside address of 192.87.167.62. Should it be routed to 192.87.167.62
> > instead?
> >
> > I didn't thoroughly anonymize the logs because I want to make sure I
> > include all the important details.
> >
> > Best,
> > Koen
> >
> >
> > On Mon, 2007-12-17 at 17:08 +0100, Jan Just Keijser wrote:
> >   
> >> Hi Koen,
> >>
> >> the server statement
> >>   push "redirect-gateway"
> >> is causing your default route to be altered; this sometimes also causes 
> >> the route to the VPN server itself to be redirected thru the VPN tunnel: 
> >> a very nice Catch-22 where all traffic for the VPN server is actually 
> >> sent thru the VPN tunnel .
> >>
> >> The solution in 99% of the cases is to add a statement like
> >>
> >> push "route 192.87.167.62 255.255.255.255 net_gateway"
> >>
> >> this will cause the traffic for the VPN server (which is 192.87 as I 
> >> read in your log files) to NOT go thru the VPN tunnel.
> >>
> >> HTH/groetjes,
> >>
> >> JJK
> >>
> >> PS It is best to anonymize log files and IP address before posting.
> >>
> >> Koen Vermeer wrote:
> >>     
> >>> Hi,
> >>>
> >>> I'm trying to set up a system where people can use openvpn to pretend
> >>> like they're part of the server's network. OpenVPN on the server is
> >>> running in a local network, connected through a NAT. The local network
> >>> is 172.17.145.0 and the server has unlimited access to the outside
> >>> world. Incoming UDP connections on the OpenVPN port are routed to the
> >>> server. The client is also in a NAT, with it's local network at
> >>> 192.168.1.0. Unfortunately, my setup doesn't seem to work. Any help is
> >>> appreciated! If more information on my setup is useful, please let me
> >>> know what else I should provide you with.
> >>>
> >>>
> >>> The server's config is:
> >>>
> >>> port 1194
> >>> proto udp
> >>> dev tap
> >>> ca ca.cer
> >>> cert server.cer
> >>> key server.key
> >>> dh DH.pem
> >>> ifconfig-pool-persist ipp.txt
> >>> server-bridge 172.17.145.20 255.255.255.0 172.17.145.70 172.17.145.90
> >>> push "redirect-gateway"
> >>> keepalive 10 120
> >>> comp-lzo
> >>> user nobody
> >>> group nogroup
> >>> persist-key
> >>> persist-tun
> >>> status openvpn-status.log
> >>> log openvpn.log
> >>> verb 3
> >>>
> >>> The client's config is:
> >>>
> >>> client
> >>> dev tap
> >>> proto udp
> >>> remote 192.87.167.62 1194
> >>> resolv-retry infinite
> >>> nobind
> >>> persist-key
> >>> persist-tun
> >>> ca ca.cer
> >>> cert client.cer
> >>> key client.key
> >>> ns-cert-type server
> >>> comp-lzo
> >>> verb 3
> >>>
> >>> The server's log is:
> >>> Mon Dec 17 15:56:59 2007 OpenVPN 2.0.9 x86_64-pc-linux-gnu [SSL] [LZO]
> >>> [EPOLL] built on May 19 2007
> >>> Mon Dec 17 15:56:59 2007 Diffie-Hellman initialized with 1024 bit key
> >>> Mon Dec 17 15:56:59 2007 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0
> >>> ET:0 EL:0 ]
> >>> Mon Dec 17 15:56:59 2007 TUN/TAP device tap0 opened
> >>> Mon Dec 17 15:56:59 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42
> >>> EB:135 ET:32 EL:0 AF:3/1 ]
> >>> Mon Dec 17 15:56:59 2007 GID set to nogroup
> >>> Mon Dec 17 15:56:59 2007 UID set to nobody
> >>> Mon Dec 17 15:56:59 2007 UDPv4 link local (bound): [undef]:1194
> >>> Mon Dec 17 15:56:59 2007 UDPv4 link remote: [undef]
> >>> Mon Dec 17 15:56:59 2007 MULTI: multi_init called, r=256 v=256
> >>> Mon Dec 17 15:56:59 2007 IFCONFIG POOL: base=172.17.145.70 size=21
> >>> Mon Dec 17 15:56:59 2007 IFCONFIG POOL LIST
> >>> Mon Dec 17 15:56:59 2007 Test_client,172.17.145.70
> >>> Mon Dec 17 15:56:59 2007 Initialization Sequence Completed
> >>> Mon Dec 17 15:57:07 2007 MULTI: multi_create_instance called
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Re-using SSL/TLS context
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 LZO compression initialized
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Control Channel MTU parms
> >>> [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Data Channel MTU parms
> >>> [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Local Options hash (VER=V4):
> >>> 'f7df56b8'
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Expected Remote Options hash
> >>> (VER=V4): 'd79ca330'
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 TLS: Initial packet from
> >>> 87.212.14.143:1563, sid=541fef01 fda297ed
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 VERIFY OK:
> >>> depth=1, /C=NL/L=Delft/O=qwerty/CN=Koen_Vermeer/emailAddress=t@xxx
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 VERIFY OK:
> >>> depth=0, /C=NL/O=i-Optics_Nederland_BV/CN=Test_client
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Data Channel Encrypt: Cipher
> >>> 'BF-CBC' initialized with 128 bit key
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Data Channel Encrypt: Using
> >>> 160 bit message hash 'SHA1' for HMAC authentication
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Data Channel Decrypt: Cipher
> >>> 'BF-CBC' initialized with 128 bit key
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Data Channel Decrypt: Using
> >>> 160 bit message hash 'SHA1' for HMAC authentication
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 Control Channel: TLSv1,
> >>> cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
> >>> Mon Dec 17 15:57:07 2007 87.212.14.143:1563 [Test_client] Peer
> >>> Connection Initiated with 87.212.14.143:1563
> >>> Mon Dec 17 15:57:08 2007 Test_client/87.212.14.143:1563 PUSH: Received
> >>> control message: 'PUSH_REQUEST'
> >>> Mon Dec 17 15:57:08 2007 Test_client/87.212.14.143:1563 SENT CONTROL
> >>> [Test_client]: 'PUSH_REPLY,redirect-gateway,route-gateway
> >>> 172.17.145.20,ping 10,ping-restart 120,ifconfig 172.17.145.70
> >>> 255.255.255.0' (status=1)
> >>> Mon Dec 17 15:57:09 2007 Test_client/87.212.14.143:1563 MULTI: Learn:
> >>> 00:ff:d0:52:4d:87 -> Test_client/87.212.14.143:1563
> >>> Mon Dec 17 15:59:41 2007 read UDPv4 [ECONNREFUSED]: Connection refused
> >>> (code=111)
> >>> [Some more of these]
> >>> Mon Dec 17 16:03:29 2007 Test_client/87.212.14.143:1563 [Test_client]
> >>> Inactivity timeout (--ping-restart), restarting
> >>> Mon Dec 17 16:03:29 2007 Test_client/87.212.14.143:1563
> >>> SIGUSR1[soft,ping-restart] received, client-instance restarting
> >>>
> >>> At the client, the log shows:
> >>>
> >>> Mon Dec 17 15:54:15 2007 OpenVPN 2.1_rc4 Win32-MinGW [SSL] [LZO2] built
> >>> on Apr 25 2007
> >>> Mon Dec 17 15:54:15 2007 LZO compression initialized
> >>> Mon Dec 17 15:54:15 2007 Control Channel MTU parms [ L:1574 D:138 EF:38
> >>> EB:0 ET:0 EL:0 ]
> >>> Mon Dec 17 15:54:15 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42
> >>> EB:135 ET:32 EL:0 AF:3/1 ]
> >>> Mon Dec 17 15:54:15 2007 Local Options hash (VER=V4): 'd79ca330'
> >>> Mon Dec 17 15:54:15 2007 Expected Remote Options hash (VER=V4):
> >>> 'f7df56b8'
> >>> Mon Dec 17 15:54:15 2007 Socket Buffers: R=[8192->8192] S=[8192->8192]
> >>> Mon Dec 17 15:54:15 2007 UDPv4 link local: [undef]
> >>> Mon Dec 17 15:54:15 2007 UDPv4 link remote: 192.87.167.62:1194
> >>> Mon Dec 17 15:54:15 2007 TLS: Initial packet from 192.87.167.62:1194,
> >>> sid=08aa98d9 04667673
> >>> Mon Dec 17 15:54:16 2007 VERIFY OK:
> >>> depth=1, /C=NL/L=Delft/O=qwerty/CN=Koen_Vermeer/emailAddress=t@xxx
> >>> Mon Dec 17 15:54:16 2007 VERIFY OK: nsCertType=SERVER
> >>> Mon Dec 17 15:54:16 2007 VERIFY OK:
> >>> depth=0, /C=NL/O=i-Optics_Nederland_BV/CN=tst
> >>> Mon Dec 17 15:54:17 2007 Data Channel Encrypt: Cipher 'BF-CBC'
> >>> initialized with 128 bit key
> >>> Mon Dec 17 15:54:17 2007 Data Channel Encrypt: Using 160 bit message
> >>> hash 'SHA1' for HMAC authentication
> >>> Mon Dec 17 15:54:17 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3
> >>> DHE-RSA-AES256-SHA, 2048 bit RSA
> >>> Mon Dec 17 15:54:17 2007 [tst] Peer Connection Initiated with
> >>> 192.87.167.62:1194
> >>> Mon Dec 17 15:54:18 2007 SENT CONTROL [tst]: 'PUSH_REQUEST' (status=1)
> >>> Mon Dec 17 15:54:18 2007 PUSH: Received control message:
> >>> 'PUSH_REPLY,redirect-gateway,route-gateway 172.17.145.20,ping
> >>> 10,ping-restart 120,ifconfig 172.17.145.70 255.255.255.0'
> >>> Mon Dec 17 15:54:18 2007 OPTIONS IMPORT: timers and/or timeouts modified
> >>> Mon Dec 17 15:54:18 2007 OPTIONS IMPORT: --ifconfig/up options modified
> >>> Mon Dec 17 15:54:18 2007 OPTIONS IMPORT: route options modified
> >>> Mon Dec 17 15:54:18 2007 OPTIONS IMPORT: route-related options modified
> >>> Mon Dec 17 15:54:19 2007 TAP-WIN32 device [Local Area Connection 2]
> >>> opened: \\.\Global\{D0524D87-70C1-457B-899A-E02B2879DB6E}.tap
> >>> Mon Dec 17 15:54:19 2007 TAP-Win32 Driver Version 9.3 
> >>> Mon Dec 17 15:54:19 2007 TAP-Win32 MTU=1500
> >>> Mon Dec 17 15:54:19 2007 Notified TAP-Win32 driver to set a DHCP
> >>> IP/netmask of 172.17.145.70/255.255.255.0 on interface
> >>> {D0524D87-70C1-457B-899A-E02B2879DB6E} [DHCP-serv: 172.17.145.0,
> >>> lease-time: 31536000]
> >>> Mon Dec 17 15:54:19 2007 Successful ARP Flush on interface [196610]
> >>> {D0524D87-70C1-457B-899A-E02B2879DB6E}
> >>> Mon Dec 17 15:54:24 2007 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0
> >>> u/d=up
> >>> Mon Dec 17 15:54:24 2007 route ADD 192.87.167.62 MASK 255.255.255.255
> >>> 192.168.1.1
> >>> Mon Dec 17 15:54:24 2007 Route addition via IPAPI succeeded [adaptive]
> >>> Mon Dec 17 15:54:24 2007 route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.1.1
> >>> Mon Dec 17 15:54:24 2007 Route deletion via IPAPI succeeded [adaptive]
> >>> Mon Dec 17 15:54:24 2007 route ADD 0.0.0.0 MASK 0.0.0.0 172.17.145.20
> >>> Mon Dec 17 15:54:24 2007 Route addition via IPAPI succeeded [adaptive]
> >>> Mon Dec 17 15:54:24 2007 Initialization Sequence Completed
> >>>
> >>> On the client, even a 'ping 172.17.145.20' doesn't work. Likewise,
> >>> browsing the internet fails (server not found).
> >>>
> >>>
> >>>   
> >>>       
> 

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users