[OpenIndiana-discuss] Cisco IPSec VPN

bentahyr at chez.com bentahyr at chez.com
Tue Nov 29 22:03:57 UTC 2016


Hi all,
Ok with match=/dev/tun and match=/dev/tap in zone configuration, it working like a charm.
I can connect to a Cisco VPN from the NGZ and keep the OpenVPN server running (and serving clients) in the GZ.

Thanks for your great work.
Something that I notice is when I stop the openconnect process, it (vpnc?) doesn't restore the /etc/resolv.conf which ends up in a non functional name resolution in the NGZ.
I'll try to check if there is a way to tell "before quitting, restore resolv.conf"


Superb!

Best regards.
Ben

----- Mail original -----
De: "Jim Klimov" <jimklimov at cos.ru>
À: "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org>, "Adam Števko" <adam.stevko at gmail.com>
Envoyé: Dimanche 27 Novembre 2016 06:52:59
Objet: Re: [OpenIndiana-discuss] Cisco IPSec VPN

26 ноября 2016 г. 14:46:17 CET, "Adam Števko" <adam.stevko at gmail.com> пишет:
>Hi,
>
>yes, they can. However, you can’t use the same tun device name e.g.
>tun0 in the GZ and NGZ as tun module is not zone aware. See
>https://github.com/joyent/smartos-live/issues/626
><https://github.com/joyent/smartos-live/issues/626>.
>
>Adam
>
>> On Nov 25, 2016, at 8:15 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>> 
>> 24 ноября 2016 г. 23:30:06 CET, bentahyr at chez.com пишет:
>>> Ok, I see.
>>> If I follow the SFE way, could I have an issue running OpenVPN
>server
>>> over TUN on GZ and wanting to run Openconnect client over TUN in NGZ
>?
>>> Like the device /dev/tun is both used in GZ and NGZ.
>>> 
>>> Best regards.
>>> Ben
>>> 
>>> ----- Mail original -----
>>> De: "Thomas Wagner" <tom-oi-discuss at tom.bn-ulm.de>
>>> À: "Discussion list for OpenIndiana"
>>> <openindiana-discuss at openindiana.org>
>>> Envoyé: Vendredi 25 Novembre 2016 10:16:51
>>> Objet: Re: [OpenIndiana-discuss] Cisco IPSec VPN
>>> 
>>> For SFE we've solved this by just adding the driver modules to the
>NGZ
>>> as dead files. So there is no install contraint regarding
>zones-type.
>>> That way the IPS dependency just matches in any case.
>>> 
>>> I use a driver match rule in the NGZ to get tun passed through:
>>> <device match="/dev/tun"/>
>>> 
>>> Thomas
>>> 
>>> On Thu, Nov 24, 2016 at 09:15:11PM +0100, bentahyr at chez.com wrote:
>>>> By the way, is there a way to install openconnect in a zone ?
>>>> I can't seem to get it running because tap driver doesn't want to
>>> install :
>>>> 
>>>> vpnzone# pkg install openconnect
>>>> Creating Plan (Running solver): |
>>>> pkg install: No matching version of network/openconnect can be
>>> installed:
>>>>  Reject: 
>>>
>pkg://openindiana.org/network/openconnect@7.7.20161105-2016.1.0.0:20161119T064832Z
>>>>  Reason:  No version matching 'require' dependency
>>> driver/network/tap can be installed
>>>>    ----------------------------------------
>>>>    Reject: 
>>>
>pkg://openindiana.org/driver/network/tap@1.3.2-2016.0.0.0:20160730T021914Z
>>>>    Reason:  This version is excluded by installed incorporation
>>> consolidation/userland/userland-incorporation at 0.5.11-2016.1.0.7919
>>>>    Reject: 
>>>
>pkg://openindiana.org/driver/network/tap@1.3.2-2016.1.0.1:20161124T055026Z
>>>> 
>>>
>pkg://openindiana.org/driver/network/tap@1.3.2-2016.1.0.1:20161124T172113Z
>>>>    Reason:  Package supports image variant
>>> variant.opensolaris.zone=[global] but doesn't support this image's
>>> variant.opensolaris.zone (nonglobal)
>>>>    ----------------------------------------
>>>>  Reject: 
>>>
>pkg://openindiana.org/network/openconnect@7.7.20161105-2016.1.0.0:20161119T114634Z
>>>>  Reason:  No version matching 'require' dependency
>>> driver/network/tap can be installed
>>>> 
>>>> 
>>>> Best regards.
>>>> Ben
>>>> 
>>>> ----- Mail original -----
>>>> De: "Jim Klimov" <jimklimov at cos.ru>
>>>> À: "Discussion list for OpenIndiana"
>>> <openindiana-discuss at openindiana.org>, "Andrey Sokolov"
>>> <keremet at solaris.kirov.ru>
>>>> Envoyé: Vendredi 25 Novembre 2016 07:07:36
>>>> Objet: Re: [OpenIndiana-discuss] Cisco IPSec VPN
>>>> 
>>>> 16 но�бр� 2016 г. 14:02:44 CET, Andrey Sokolov
>>> <keremet at solaris.kirov.ru> пишет:
>>>>> Hi!
>>>>> I use
>>>> 
>>>>
>http://pkg.openindiana.org/sfe/info/0/system%2Fnetwork%2Fvpnc%400.5.3%2C5.11-0.151.1.5%3A20120819T093748Z
>>>>> 
>>>>> 2016-11-14 15:35 GMT+03:00 Jim Klimov <jimklimov at cos.ru>:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I am faced with a prospect of connecting to a remote network
>>> behind
>>>>> Cisco
>>>>>> IPSec VPN (the one with user, password, group and shared keys;
>>> will
>>>>> be
>>>>>> practically trying sometime soon this week). Should I expect it
>to
>>>>> work in
>>>>>> OI Hipster out of the box? Are there docs/blogs on it, or would
>>>>> Oracle docs
>>>>>> I found so far (some hints about conf files and then ipadm tun
>>>>> commands) be
>>>>>> relevant here? Or should I try some other OS right away?
>>>>>> 
>>>>>> TIA, Jim
>>>>>> --
>>>>>> Typos courtesy of K-9 Mail on my Samsung Android
>>>>>> 

>>>> Thanks,
>>>> 
>>>> In the end vpnc did work for me; also I saw that openconnect could
>>> connect to Juniper/Cisco SSL VPNs... so I couldn't resist and now
>both
>>> are packaged in OI/Hipster userland ;)
>>>> 
>>>> Thanks,
>>>> Jim
>>>> --
>>>> Typos courtesy of K-9 Mail on my Samsung Android
>>>> 
>>>> 
>>> 
>>> -- 
>>> -- 
>>> Thomas Wagner
>>> 

>> 
>> I think this coexistence should not be a problem - several programs
>can call the tun/tap driver interfaces to spawn and tear down virtual
>tunX or tapY IP interfaces. I don't think it matters from which zone
>the request comes to the driver, although with 'match' it may be that
>all zones will see all such NICs (not sure about IP side). So far I
>used openvpn in either a gz or ngz on a single machine, so do not have
>practice mixing that (would ip stack go crazy or not?).
>> 
>> If you can experiment and find this does not blow up to coexist,
>please write ;) PRs also welcome, but at least info from the trenches
>would be good...
>> 
>> Jim
>> --
>> Typos courtesy of K-9 Mail on my Samsung Android
>> 

Indeed, you can not tell several apps (safely) to use e.g. tun0 regardless of the zone, at least not if they are meant to use the same tunnel and are allowed to. Usually this is not an issue however, since apps are told to use just 'tun' or 'tap' so they allocate, use and later release the numbered device instance. As i found, there are different flags (persistent or not device allocation in particular) in the API for this, the former does not deallocate the device automatically if the service died ungracefully for example. 

There is also a 'tunctl' to bind and tear down tun/tap devices so you can provide control external to an app and/or rectify its faults to clean up.

Jim

--
Typos courtesy of K-9 Mail on my Samsung Android





More information about the openindiana-discuss mailing list