[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: Tue, 18 Dec 2007 10:19:30 +0100

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