[lug] OpenVPN second instance on a server not working
Carl Wagner
carl.wagner at verbalworld.com
Thu Sep 9 09:54:19 MDT 2010
David,
Routing was my first thought as well. Except the routing looks the same
for both instances.
Yes the default route is over the eth device.
Source IP: (captured on the VPN server)
=======
# tcpdump -i tun1 icmp
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
08:25:03.625079 IP 10.0.12.10 > 10.0.12.1: ICMP echo request, id 768,
seq 18432, length 40
08:25:09.114245 IP 10.0.12.10 > 10.0.12.1: ICMP echo request, id 768,
seq 18688, length 40
08:25:14.615013 IP 10.0.12.10 > 10.0.12.1: ICMP echo request, id 768,
seq 18944, length 40
08:25:20.114422 IP 10.0.12.10 > 10.0.12.1: ICMP echo request, id 768,
seq 19200, length 40
=======
So that looks OK.
The reason I want 2 instances is because it is a remote box (about an
hour drive) and I want to do some testing to allow an entire client lan
to use the tunnel. But I don't want to break the functioning link
requiring a trip (or multiple trips if I break it multiple times). Plus
I have been fighting this long enough that I really want to know why it
isn't working.
I did a quick search on the tcpdump WARNING above and thought I found
something:
http://openvpn.net/archive/openvpn-users/2006-03/msg00307.html
The title looked promising: "
[Openvpn-users] Stupid tunnel routing problem..
To simplify things, on the server instance 2 config file, I commented
out the chroot and cd commands.
Then following what they said in the above link (actuall the second
posting in the thread), I uncommented the route statement
route 192.168.0.0 255.255.255.0
and created the file:
client/cwagnerwork {matches the certificate name}
which contains:
=====
# File name: cwagner
# Route this LAN over the VPN
iroute 192.168.0.0 255.255.255.0
=====
Note: this was the actual object of the exercise, to allow the
192.168.0.x local lan to route over the VPN.
But it did not help.
openvpn-status_i2.log
=====
OpenVPN CLIENT LIST
Updated,Thu Sep 9 09:11:10 2010
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
cwagnerwork,209.x.x.x:2393,11145,11153,Thu Sep 9 08:59:03 2010
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
192.168.0.0/24,cwagnerwork,209.x.x.x:2393,Thu Sep 9 08:59:06 2010
10.0.12.6,cwagnerwork,209.x.x.x:2393,Thu Sep 9 08:59:38 2010
GLOBAL STATS
Max bcast/mcast queue length,0
END
=====
openvpn_i2.log
=====
Thu Sep 9 08:58:40 2010 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO]
[EPOLL] built on Sep 20 2007
Thu Sep 9 08:58:40 2010 Diffie-Hellman initialized with 2048 bit key
Thu Sep 9 08:58:40 2010 Control Channel Authentication: using 'tls-auth'
as a OpenVPN static key file
Thu Sep 9 08:58:40 2010 Outgoing Control Channel Authentication: Using
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 9 08:58:40 2010 Incoming Control Channel Authentication: Using
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 9 08:58:40 2010 TLS-Auth MTU parms [ ...]
Thu Sep 9 08:58:40 2010 TUN/TAP device tun1 opened
Thu Sep 9 08:58:40 2010 ifconfig tun1 10.0.12.1 pointopoint 10.0.12.2
mtu 1500
Thu Sep 9 08:58:40 2010 route add -net 192.168.0.0 netmask 255.255.255.0
gw 10.0.12.2
Thu Sep 9 08:58:40 2010 route add -net 10.0.12.0 netmask 255.255.255.0
gw 10.0.12.2
Thu Sep 9 08:58:40 2010 Data Channel MTU parms [ ... ]
Thu Sep 9 08:58:40 2010 GID set to openvpn
Thu Sep 9 08:58:40 2010 UID set to openvpn
Thu Sep 9 08:58:40 2010 UDPv4 link local (bound): [undef]:1294
Thu Sep 9 08:58:40 2010 UDPv4 link remote: [undef]
Thu Sep 9 08:58:40 2010 MULTI: multi_init called, r=256 v=256
Thu Sep 9 08:58:40 2010 IFCONFIG POOL: base=10.0.12.4 size=62
Thu Sep 9 08:58:40 2010 IFCONFIG POOL LIST
Thu Sep 9 08:58:40 2010 Initialization Sequence Completed
Thu Sep 9 08:59:03 2010 MULTI: multi_create_instance called
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 Re-using SSL/TLS context
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 LZO compression initialized
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 Control Channel MTU parms [ ... ]
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 Data Channel MTU parms [ ... ]
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 Local Options hash (VER=V4):
'........'
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 Expected Remote Options hash
(VER=V4): '........'
Thu Sep 9 08:59:03 2010 209.x.x.x:2393 TLS: Initial packet from
209.x.x.x:2393, sid=........ ........
Thu Sep 9 08:59:05 2010 209.x.x.x:2393 VERIFY OK: depth=1, /C=US/ST=CO/ ...
Thu Sep 9 08:59:05 2010 209.x.x.x:2393 VERIFY OK: depth=0,
/C=US/ST=CO/L= ...
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 Data Channel Encrypt: Cipher
'....' initialized with 128 bit key
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 Data Channel Encrypt: Using 160
bit message hash 'SHA1' for HMAC authentication
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 Data Channel Decrypt: Cipher
'....' initialized with 128 bit key
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 Data Channel Decrypt: Using 160
bit message hash 'SHA1' for HMAC authentication
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 Control Channel: TLSv1, cipher
TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Thu Sep 9 08:59:06 2010 209.x.x.x:2393 [cwagnerwork] Peer Connection
Initiated with 209.x.x.x:2393
Thu Sep 9 08:59:06 2010 cwagnerwork/209.x.x.x:2393 OPTIONS IMPORT:
reading client specific options from: clients/cwagnerwork
Thu Sep 9 08:59:06 2010 cwagnerwork/209.x.x.x:2393 MULTI: Learn:
10.0.12.6 -> cwagnerwork/209.x.x.x:2393
Thu Sep 9 08:59:06 2010 cwagnerwork/209.x.x.x:2393 MULTI: primary
virtual IP for cwagnerwork/209.x.x.x:2393: 10.0.12.6
Thu Sep 9 08:59:06 2010 cwagnerwork/209.x.x.x:2393 MULTI: internal route
192.168.0.0/24 -> cwagnerwork/209.x.x.x:2393
Thu Sep 9 08:59:06 2010 cwagnerwork/209.x.x.x:2393 MULTI: Learn:
192.168.0.0/24 -> cwagnerwork/209.x.x.x:2393
Thu Sep 9 08:59:07 2010 cwagnerwork/209.x.x.x:2393 PUSH: Received
control message: 'PUSH_REQUEST'
Thu Sep 9 08:59:07 2010 cwagnerwork/209.x.x.x:2393 SENT CONTROL
[cwagnerwork]: 'PUSH_REPLY,route 10.0.12.1,ping 10,ping-restart
60,ifconfig 10.0.12.6 10.0.12.5' (status=1)
Let me know if I redacted to much info (or not enough).
Any ideas?
Thanks,
Carl.
David L. Anselmi wrote:
> Carl Wagner wrote:
>
>> Hi,
>>
>> I have having problems getting a second instance of OpenVPN working.
>>
> [...]
>
>> tun1 Link encap:UNSPEC HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet
>> addr:10.0.12.1 P-t-P:10.0.12.2 Mask:255.255.255.255
>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
>> RX packets:159 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:8100 (7.9 KiB) TX bytes:0 (0.0 b)
>>
>
> I'm guessing a routing problem, because tun1 isn't transmitting. The server is getting your echo
> requests but isn't trying to send the replies through tun1.
>
> What's the source IP of the echo requests? It has to be 10.0.12.x or the replies won't come back
> through the tunnel.
>
> If you can see the requests on the server then the client routing is probably correct. The server
> routing seems to be also (I assume the default gateway uses the eth device). So client source
> address seems most likely to me.
>
>
>> Destination Gateway Genmask Flags Metric Ref Use Iface
>> 10.0.12.2 * 255.255.255.255 UH 0 0 0 tun1
>> 10.0.12.0 10.0.12.2 255.255.255.0 UG 0 0 0 tun1
>>
>
> This matches what my VPN server uses.
>
> Why do you want two instances? One instance can manage multiple connections.
>
> Dave
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100909/e6ad7b18/attachment.html>
More information about the LUG
mailing list