[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 22:55:51 +0100

Hi Koen,

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. 

Can you try 
- changing to a 'tun' setup
- using a different subnet for the VPN, e.g. 172.17.146.0/24 ?

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).

HTH,

JJK



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-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users