[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 17:59:12 +0100

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