Multiple simultaneous tap interfaces config issue.

Got a problem with Viscosity or need help? Ask here!

henrikk

Posts: 14
Joined: Wed Apr 03, 2013 6:18 am

Post by henrikk » Wed Apr 03, 2013 6:41 am
Does OpenVPN and/r viscosity support multiple simultaneous VPN/tap connections? If it should, I have a configuration issue.

I have two VPN tap connections to two different OpenVPN servers. Both are configured to use TCP (if that matters) and both connect to different subnets. Each of them works independent of the other, When I try to connect both, the second connection establishes and works, but the first one ceases to work (though it "stays" connected). The issue appears to be that the fist VPN tap/interface looses its IP address. I can type 'ifconfig' and verify the tap interface has an assigned IP. As soon as the second tap interface is established, the first stops reporting an IP address.

Note that if I configure both OpenVPN servers to use 'tun' then it works just fine. Both VPN connections work at the same time.

One more data point. If I connect first using 'tap' (1st server) and then 'tun' (2nd server) the 1st tap connection looses it IP as well. If I do it the other way around: 1st 'tun' and then 'tap' both interface retain their correct IP's and everything works.

Any ideas on what i might be doing wrong? Should two simultaneous 'tap' interfaces work?

I am using MacOSX 10.8.3. Thanks.

- Henrik

James

User avatar
Posts: 1985
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Apr 05, 2013 5:15 am
Hi Henrik,

It should - a quick test on my end with two simultaneous TAP connections didn't have an issue. I guess more information is needed at this stage:

1. How are the IP addresses for your connections assigned? Both by OpenVPN? Both by a remote DHCP server? One of each?

2. Are either of the connections directed to have all traffic routed through them (i.e. a default route is being created)? Considering the order appears to matter, it sounds likely that one may have all traffic flowing through it, while the second is set up for split-routing (which is ideally what you'd want from both of them).

3. Are there any warning messages or errors in the OpenVPN log from either of the connections? Are there any messages from Viscosity indicating it is turning off DHCP for a connection as it isn't needed?
http://www.sparklabs.com/support/viewin ... envpn_log/

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

henrikk

Posts: 14
Joined: Wed Apr 03, 2013 6:18 am

Post by henrikk » Wed Apr 10, 2013 10:21 am
OK, I need to look at the logs and configuration. Will get back as soon as I can.

- Henrik

henrikk

Posts: 14
Joined: Wed Apr 03, 2013 6:18 am

Post by henrikk » Sat Apr 13, 2013 12:04 am
Hello James,
OK, I really would like this to work. Thanks for the reponse.
James wrote:
1. How are the IP addresses for your connections assigned? Both by OpenVPN? Both by a remote DHCP server? One of each?
Both tap interfaces are assigned by DHCP from the OpenVPN servers.
James wrote:
2. Are either of the connections directed to have all traffic routed through them (i.e. a default route is being created)? Considering the order appears to matter, it sounds likely that one may have all traffic flowing through it, while the second is set up for split-routing (which is ideally what you'd want from both of them).
Neither of the connection is having all traffic go through them. They only are used to access the subnets on the OpenVPN server side, I can confirm this works individually. I am using different subnets for both OpenVPN hosts,
James wrote:
3. Are there any warning messages or errors in the OpenVPN log from either of the connections? Are there any messages from Viscosity indicating it is turning off DHCP for a connection as it isn't needed?
http://www.sparklabs.com/support/viewin ... envpn_log/
There is no messages about DHCP being turned off. I did check the logs and can find nothing relevant.

Let me provide you with some additional information. When I 'tap' connect to the first server (order does not matter), the connection goes well, IP is assigned:
Code: Select all
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether da:cf:bc:83:ba:a3 
	inet 192.168.9.202 netmask 0xffffff00 broadcast 192.168.9.255
	open (pid 10786)
The logs seem OK:
Code: Select all
Apr 12 08:51:48: Viscosity Mac 1.4.3 (1114)
Apr 12 08:51:48: Viscosity OpenVPN Engine Started
Apr 12 08:51:48: Running on Mac OS X 10.8.3
Apr 12 08:51:48: ---------
Apr 12 08:51:48: Checking reachability status of connection...
Apr 12 08:51:49: Connection is reachable. Starting connection attempt.
Apr 12 08:51:51: OpenVPN 2.2.1 x86_64-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Aug  1 2011
Apr 12 08:51:50: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 12 08:51:50: LZO compression initialized
Apr 12 08:51:50: UDPv4 link local: [undef]
Apr 12 08:51:50: UDPv4 link remote: x.x.x.x:1195
Apr 12 08:51:51: [server] Peer Connection Initiated with x.x.x.x:1195
Apr 12 08:51:55: DHCP enabled on tap interface tap0
Apr 12 08:51:54: TUN/TAP device /dev/tap0 opened
Apr 12 08:51:54: Initialization Sequence Completed
Apr 12 08:51:54: write to TUN/TAP : Input/output error (code=5)
Apr 12 08:51:54: write to TUN/TAP : Input/output error (code=5)
and I can verify it works. Now I connect to the second 'tap' server. The second interface gets its IP and the first "looses" it:
Code: Select all
tap0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether da:cf:bc:83:ba:a3 
	open (pid 10786)
tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether ee:09:bc:20:22:d0 
	inet 192.168.3.155 netmask 0xffffff00 broadcast 192.168.3.255
	open (pid 10870)
I can now access the second subnet, but not the first. Log files:
Code: Select all
Apr 12 08:53:49: Viscosity Mac 1.4.3 (1114)
Apr 12 08:53:49: Viscosity OpenVPN Engine Started
Apr 12 08:53:49: Running on Mac OS X 10.8.3
Apr 12 08:53:49: ---------
Apr 12 08:53:49: Checking reachability status of connection...
Apr 12 08:53:49: Connection is reachable. Starting connection attempt.
Apr 12 08:53:51: OpenVPN 2.2.1 x86_64-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Aug  1 2011
Apr 12 08:53:51: NOTE: --mute triggered...
Apr 12 08:53:51: 2 variation(s) on previous 3 message(s) suppressed by --mute
Apr 12 08:53:51: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 12 08:53:51: LZO compression initialized
Apr 12 08:53:51: Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Apr 12 08:53:51: Socket Buffers: R=[196724->65536] S=[9216->65536]
Apr 12 08:53:51: MANAGEMENT: >STATE:1365774831,RESOLVE,,,
Apr 12 08:53:51: Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Apr 12 08:53:51: Local Options hash (VER=V4): 'd79ca330'
Apr 12 08:53:51: Expected Remote Options hash (VER=V4): 'f7df56b8'
Apr 12 08:53:51: UDPv4 link local: [undef]
Apr 12 08:53:51: UDPv4 link remote: x.x.x.x:1195
Apr 12 08:53:51: MANAGEMENT: >STATE:1365774831,WAIT,,,
Apr 12 08:53:51: MANAGEMENT: >STATE:1365774831,AUTH,,,
Apr 12 08:53:51: TLS: Initial packet from x.x.x.x:1195, sid=234ca17d 0a2b7745
Apr 12 08:53:51: MANAGEMENT: CMD 'hold release'
Apr 12 08:53:52: VERIFY OK: depth=1, /C=US/ST=TX/L=Austin/O=Berry_Consultants_LLC/OU=./CN=Berry_Consultants_LLC_CA/name=BerryCA/[email protected]
Apr 12 08:53:52: VERIFY OK: nsCertType=SERVER
Apr 12 08:53:52: VERIFY OK: depth=0, /C=US/ST=TX/L=Austin/O=Berry_Consultants_LLC/OU=./CN=server/name=server/[email protected]
Apr 12 08:53:52: MANAGEMENT: CMD 'state on'
Apr 12 08:53:52: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 12 08:53:52: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 12 08:53:52: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 12 08:53:52: NOTE: --mute triggered...
Apr 12 08:53:52: 2 variation(s) on previous 3 message(s) suppressed by --mute
Apr 12 08:53:52: [server] Peer Connection Initiated with x.x.x.x:1195
Apr 12 08:53:52: MANAGEMENT: CMD 'hold release'
Apr 12 08:53:52: MANAGEMENT: CMD 'pid'
Apr 12 08:53:52: MANAGEMENT: CMD 'pid'
Apr 12 08:53:53: NOTE: --mute triggered...
Apr 12 08:53:53: 1 variation(s) on previous 3 message(s) suppressed by --mute
Apr 12 08:53:53: MANAGEMENT: >STATE:1365774833,GET_CONFIG,,,
Apr 12 08:53:53: MANAGEMENT: CMD 'pid'
Apr 12 08:53:53: MANAGEMENT: CMD 'pid'
Apr 12 08:53:54: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Apr 12 08:53:54: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.3.1,route-gateway dhcp,ping 15,ping-restart 60'
Apr 12 08:53:54: OPTIONS IMPORT: timers and/or timeouts modified
Apr 12 08:53:54: OPTIONS IMPORT: route-related options modified
Apr 12 08:53:54: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Apr 12 08:53:56: DHCP enabled on tap interface tap1
Apr 12 08:53:54: TUN/TAP device /dev/tap1 opened
Apr 12 08:53:54: Initialization Sequence Completed
Apr 12 08:53:54: MANAGEMENT: >STATE:1365774834,CONNECTED,SUCCESS,,x.x.x.x
Apr 12 08:53:55: write to TUN/TAP : Input/output error (code=5)
Apr 12 08:53:56: MANAGEMENT: CMD 'status'
Apr 12 08:53:57: MANAGEMENT: CMD 'status'
Apr 12 08:53:58: MANAGEMENT: CMD 'status'
Apr 12 08:53:59: NOTE: --mute triggered...

James

User avatar
Posts: 1985
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Apr 26, 2013 4:20 pm
Hi henrikk,

We were finally able to replicate this issue, and we think we've managed to solve it in the latest beta version. Please give it a test and let us know how you get on:
http://www.sparklabs.com/forum/viewtopic.php?p=134#p134

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

henrikk

Posts: 14
Joined: Wed Apr 03, 2013 6:18 am

Post by henrikk » Mon Apr 29, 2013 11:04 pm
I posted in the thread referenced above, but to confirm. The beta Viscosity 1.4.4b5 resolves this issue for me. Thanks.

- Henrik
6 posts Page 1 of 1