[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: Wed, 02 Jan 2008 14:36:40 +0100

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