[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: Jan Just Keijser <janjust@xxxxxxxxx>
  • Date: Fri, 21 Dec 2007 17:06:00 +0100

OK, let's step back here for a minute. Your original problem was:

Mon Dec 17 15:59:41 2007 read UDPv4 [ECONNREFUSED]: Connection refused 
(code=111)

this means the client and server could not talk to each other.
We've now established that you *can* talk/ping the server. What does the 
server log now show ? still the same 'code=111' errors? Is that any 
different when done with or without the 'redirect-gateway' directive?

cheers,

JJK

Koen Vermeer wrote:
> 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