pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [Openvpn-users] openvpn, no errors but no workie...
Hello Jan,
We have been carefull to exclude the private subnet from our
networks---once bitten twice shy. ;-)
Good news, the problem is solved! I considered building wireshark for
this but a ping flood and check of blinkin lights confirmed what I had
assumed, the vpn packets got to the server host and never left. I had
all but wrote it off as nobody ever tested tap vpn on NetBSD when I
stumbled across a config I missed.
I don't think this is in the OpenVPN docs and would appreciate if these
comments where rolled in, consider them public domain.
Like all BSD variants, the tap method requires a kernel with
tap, bridge and GATEWAY enabled in the kernel. The sysctl option
for packet forwarding must be set. (In NetBSD that would be
net.inet.ip.forwarding=1, typically from /etc/sysctl.conf at boot)
The last line of the config file specifies the location of a script to
run on startup:
up /usr/local/etc/openvpn/bridgeup.sh
This script brings up the tap interface and assigns it a dummy address
so it doesn't go back down. It is also important to bridge the tap
interface to the lan interface so packets will leave the box! (They
won't route out of the tap interface without it.) For example
#!/bin/sh
# make an ip to bring up the tap interface
ifconfig $1 192.168.254.254 netmask 255.255.255.255
# make bridge0 to pass through the tap interface to the private network :)
ifconfig create bridge0
brconfig bridge0 add $1 add nfe0 up
Be sure to specify the correct interface for the LAN (on this host it is
nfe0) the tap interface (typically tap0) is passed to the script as $1
by openvpn.
greetings, George
On Tue 15 Jul 2008 at 10:01:06 AM +0200, Jan Just Keijser wrote:
>Hi George,
>
>err, if this is a local routing issue then there's very little I can
>do/think of from here... A small thing to try is to change the IP range
>of your openvpn - perhaps a router somewhere along the way also likes
>the 192.168.15.0/24 subnet ... try switching to a completely different
>range (for debugging purposes), e.g. 172.16.29.0/24
>
>HTH,
>
>JJK
>
>George Georgalis wrote:
>> Hi Jan,
>>
>> yes, no firewall on vpn server, I'm looking at the ISP router
>> (it was replaced Friday, seems to have failed same time the vpn
>> did) as a potential source of the problem. It is not properly
>> nat-ing from it's dhcp network and ISP thinks it's acting kookie.
>> (running openvpn server on i386 host didn't change anything);
>> maybe something is broke in the static routing (isp router) where
>> the vpn server is, too?
>>
>> // George
>>
>>
>> On Mon 14 Jul 2008 at 03:48:42 PM +0200, Jan Just Keijser wrote:
>>
>>> Hi George,
>>>
>>>
>> >from the log file it looks like the client is connecting just fine and
>>
>>> 'ping' between client and server seems to be working as well at the
>>> openvpn level : the only thing left to check (again) is the firewall...
>>> also, try running wireshark/tcpdump on the server and (for debugging
>>> purposes) set the cipher to 'none' so that you can see unencrypted
>>> openvpn packets.
>>>
>>> cheers,
>>>
>>> JJK
>>>
>>> George Georgalis wrote:
>>>
>>>> Hello Jan,
>>>>
>>>> On Mon 14 Jul 2008 at 10:05:05 AM +0200, Jan Just Keijser wrote:
>>>>
>>>>
>>>>> set
>>>>> verb 5
>>>>> in the server config file, move aside the 'ipp.txt' file for now,
>>>>> connect a client again and post the server log file during the connection
>>>>>
>>>>>
>>>> Okay, here we go...
>>>>
>>>>
>>>> Mon Jul 14 08:25:38 2008 us=3349 IFCONFIG POOL: base=192.168.15.200 size=51
>>>> Mon Jul 14 08:25:38 2008 us=3379 Initialization Sequence Completed
>>>> Mon Jul 14 08:25:46 2008 us=200915 MULTI: multi_create_instance called
>>>> RMon Jul 14 08:25:46 2008 us=201052 70.183.8.249:52494 Re-using SSL/TLS
>>>> context
>>>> Mon Jul 14 08:25:46 2008 us=201241 70.183.8.249:52494 Control Channel MTU
>>>> parms [ L:1573 D:138 EF:38 EB:0 ET:0 EL:0 ]
>>>> Mon Jul 14 08:25:46 2008 us=201254 70.183.8.249:52494 Data Channel MTU
>>>> parms [ L:1573 D:1450 EF:41 EB:4 ET:32 EL:0 ]
>>>> Mon Jul 14 08:25:46 2008 us=201278 70.183.8.249:52494 Local Options
>>>> String: 'V4,dev-type tap,link-mtu 1573,tun-mtu 1532,proto UDPv4,cipher
>>>> BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
>>>> Mon Jul 14 08:25:46 2008 us=201286 70.183.8.249:52494 Expected Remote
>>>> Options String: 'V4,dev-type tap,link-mtu 1573,tun-mtu 1532,proto
>>>> UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
>>>> Mon Jul 14 08:25:46 2008 us=201314 70.183.8.249:52494 Local Options hash
>>>> (VER=V4): '0ddbb6e3'
>>>> Mon Jul 14 08:25:46 2008 us=201330 70.183.8.249:52494 Expected Remote
>>>> Options hash (VER=V4): '2c50bd2c'
>>>> WMon Jul 14 08:25:46 2008 us=201492 70.183.8.249:52494 TLS: Initial packet
>>>> from 70.183.8.249:52494, sid=5e7e5f49 763dfdf1
>>>> RRWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRRRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRMon
>>>> Jul 14 08:25:46 2008 us=893443 70.183.8.249:52494 VERIFY OK: depth=1,
>>>> /C=US/ST=CT/L=Tariffville/O=Metrum_Research_Group_LLC/OU=Certificate_Authority/CN=vpn.metrumresearch.com/emailAddress=george%iuxta.com@localhost
>>>> WMon Jul 14 08:25:46 2008 us=893722 70.183.8.249:52494 VERIFY OK: depth=0,
>>>> /C=US/ST=CT/O=Metrum_Research_Group_LLC/OU=Information_System_Scientist/CN=George_Georgalis_fuji_2007.07.27.1854.07/emailAddress=georgeg%metrumrg.com@localhost
>>>> RWRWRWRWRWRMon Jul 14 08:25:46 2008 us=961265 70.183.8.249:52494 Data
>>>> Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
>>>> WMon Jul 14 08:25:46 2008 us=961328 70.183.8.249:52494 Data Channel
>>>> Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>>>> Mon Jul 14 08:25:46 2008 us=961383 70.183.8.249:52494 Data Channel
>>>> Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
>>>> Mon Jul 14 08:25:46 2008 us=961397 70.183.8.249:52494 Data Channel
>>>> Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>>>> WWRRRMon Jul 14 08:25:47 2008 us=71008 70.183.8.249:52494 Control Channel:
>>>> TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
>>>> Mon Jul 14 08:25:47 2008 us=71078 70.183.8.249:52494
>>>> [George_Georgalis_fuji_2007.07.27.1854.07] Peer Connection Initiated with
>>>> 70.183.8.249:52494
>>>> RMon Jul 14 08:25:48 2008 us=220661
>>>> George_Georgalis_fuji_2007.07.27.1854.07/70.183.8.249:52494 PUSH: Received
>>>> control message: 'PUSH_REQUEST'
>>>> WMon Jul 14 08:25:48 2008 us=220769
>>>> George_Georgalis_fuji_2007.07.27.1854.07/70.183.8.249:52494 SENT CONTROL
>>>> [George_Georgalis_fuji_2007.07.27.1854.07]: 'PUSH_REPLY,route 192.168.15.0
>>>> 255.255.255.0,route-gateway 192.168.15.85,ping 10,ping-restart
>>>> 120,ifconfig 192.168.15.200 255.255.255.0' (status=1)
>>>> WWWRRRRMon Jul 14 08:25:48 2008 us=373797
>>>> George_Georgalis_fuji_2007.07.27.1854.07/70.183.8.249:52494 MULTI: Learn:
>>>> 8e:44:fd:b9:eb:3c ->
>>>> George_Georgalis_fuji_2007.07.27.1854.07/70.183.8.249:52494
>>>>
>>>> ...additionally, I can see my unresponsive pings as
>>>> wRwRwRwRwRWwRwRwRwWRWRWRW after that connection.
>>>>
>>>> I'm thinking I should put this on i386? as the original
>>>> server was, the (yet to be working) replacement is
>>>> amd64.
>>>>
>>>> // George
>>>>
>>>>
>>>>
>>>>
>>>>> George Georgalis wrote:
>>>>>
>>>>>
>>>>>> I deployed openvpn a few years ago on a FreeBSD box and
>>>>>> it has worked flawlessly. But the other day the hardware
>>>>>> failed and I put the config and keys on a netbsd-4
>>>>>> box. The daemon starts up normal, and clients initialize
>>>>>> quickly. It is a tap based vpn, and the route is pushed
>>>>>> by the server, but not the gateway or ns.
>>>>>>
>>>>>> Besides all the logs not showing errors, the clients do
>>>>>> get a proper route added for the remote subnet, eg this
>>>>>> IP is on the remote side of the connection:
>>>>>>
>>>>>> # route get 192.168.15.1
>>>>>> route to: 192.168.15.1
>>>>>> destination: 192.168.15.0
>>>>>> mask: 255.255.255.0
>>>>>> interface: tap0
>>>>>> flags: <UP,DONE,CLONING>
>>>>>> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu
>>>>>> expire
>>>>>> 0 0 0 0 0 0 1500
>>>>>> -122
>>>>>>
>>>>>> the vpn server lan ip and subnet show in my client
>>>>>> routing table...
>>>>>>
>>>>>> 192.168.15 link#7 UC 1 0 tap0
>>>>>> 192.168.15.85 link#7 UHLW 0 0 tap0
>>>>>>
>>>>>> and you can see my client connection in the status log
>>>>>>
>>>>>> Virtual Address,Common Name,Real Address,Last Ref
>>>>>> ae:fa:86:7a:84:a9,George_Georgalis_fuji_2007.07.27.1854.07,70.183.8.249:63779,Sun
>>>>>> Jul 13 21:33:15 2008
>>>>>>
>>>>>> but that's it. no workie. I can't ping the client ip
>>>>>> from the cooresponding ipp.txt:
>>>>>>
>>>>>> George_Georgalis_fuji_2007.07.27.1854.07,192.168.15.229
>>>>>>
>>>>>> (I'm not sure where else I might find that IP on the
>>>>>> server, it's not in the arp table), nor can I reach any
>>>>>> other ip on the remote subnet, including the server's
>>>>>> lan IP.
>>>>>>
>>>>>> I've turned off all firewalling and I can reach the
>>>>>> private subnet from a shell on the vpn server.
>>>>>>
>>>>>> What could be the problem here?
>>>>>>
>>>>>> // George
>>>>>>
>>>>>>
>>>>
>>>>
>
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Openvpn-users mailing list
>Openvpn-users%lists.sourceforge.net@localhost
>https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
--
George Georgalis, information system scientist <IXOYE><
Home |
Main Index |
Thread Index |
Old Index