[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: Wed, 09 Jan 2008 01:30:36 +0100

Hi Koen,

ah this is a bridging setup - haven't you read that bridging setups are 
evil  ;-) ?
why do you need tap/bridging? are you using non-IP traffic? 
multicast/broadcast traffic ?

I am not very familiar with bridging setups and don't have the time 
right now to look into this. Perhaps somebody else on this list knows of 
a good bridging tutorial?

cheers,

JJK

Koen Vermeer wrote:
> [Oops, I pressed reply instead of reply-to-all. Retrying...]
>
> Hi Jan Just,
>
> So, holidays are over and I'm back to trying to fix this... Sorry for
> the delay - it may make it seems like I don't care about your comments,
> but I do appreciate the help!
>
>
> On Fri, 2007-12-21 at 22:55 +0100, Jan Just Keijser wrote:
>   
>> ah OK, the client log file was confusing me there, I guess...
>> there's another remark you made that struck me as odd:
>>     
>>> 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.
>>>       
>> does this mean the internal network on the VPN server is 172.17.145.0/24? that would imply that your local network has the same IP space as your VPN. That won't work unless you're using bridging. 
>>     
>
> I'm not sure what causes all the confusion, but the internal network on
> the VPN server side is 172.17.145.0/24. The VPN server itself is .20,
> the clients should get .70-.90. The gateway is at .1.
>
> My local network (at the client's side) is 192.168.1.0/24. The client is
> at .100 or something like that (dynamic), and its gateway is at .1. It
> then goes to 192.168.2.1 (the internal IP of my modem) and on to the
> internet.
>
> I started out with 192.168.1.0/24 at work as well, but I changed it to
> 172.17.145.0/24 to actually try to prevent confusion like this... :-)
>
> I am indeed running in bridging mode. As I said, I'm new to this, and I
> got the impression that if you want to support multiple clients on one
> OpenVPN server and if you want the clients to become part of the VPN's
> internal network, bridging was the way to go. I had already set up
> bridging on this server (to support virtual servers).
>
>   
>> Can you try 
>> - changing to a 'tun' setup
>>     
>
> If that setup will support my intended use, I'd be happy to use a tun
> setup. I have no real preference for either tun or tap - yet. But before
> changing things, can you confirm that it would match my intended use?
>
>   
>> - using a different subnet for the VPN, e.g. 172.17.146.0/24 ?
>>     
>
> As explained above, the VPN is at 172.17.145.0/24, and the client is at
> 192.168.1.0/24, so I guess I can ignore this. Unless you mean that the
> VPN itself should be in yet another subnet.
>
>   
>> make sure that routing is enabled on the openvpn server:
>>  echo 1 > /proc/sys/net/ipv4/ip_foward
>> (will be reset when the system is rebooted). Also, try using Masquerading to avoid routing issues with your LAN:
>>   iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
>> (again, this setting will hold until a reboot).
>>     
>
> I guess this applies to a tun setup only, right? I was under the
> impression that in bridging mode, the traffic should find its way
> through the network 'automatically'.
>
> Best,
> Koen
>
>
>   
>> Koen Vermeer wrote:
>>     
>>> Hi Jan Just,
>>>
>>> I don't think that was the problem. I googled for that error and it
>>> seems it has something to do with detecting a loss of connection. I
>>> never meant to imply that that error was the one I was trying to solve. 
>>>
>>> My problem was that, after connecting, I couldn't open an internet page.
>>> At that time, the code=111 error does not appear. Only when I
>>> disconnect, the error shows up on the server.
>>>
>>> Without the 'redirect-gateway', the server shows the same behaviour. I
>>> did notice that, without the 'redirect-gateway', I can access the
>>> internet, but it doesn't go through the openvpn server.
>>>
>>> Best,
>>> Koen
>>>
>>>
>>> On Fri, 2007-12-21 at 17:06 +0100, Jan Just Keijser wrote:
>>>   
>>>       
>>>> 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 mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users