[Swan] updown script not called with mast

Fri Dec 12 13:59:04 EET 2014

Am Donnerstag, 11. Dezember 2014, 22:34:11 schrieb Paul Wouters:
> On Thu, 11 Dec 2014, Michael Schwartzkopff wrote:
> > I did a little research on my problem. It seems the updown script is not
> > called if I use the mast protostack.
> 
> Be aware that the _updown script calls _updown.{protostack} script. So
> for most people _updown calls _updown.netkey. In your case it is
> supposed to call _updown.mast
> 
> > When I use the klips stack, the scipt is called. When I only change the
> > protostack and interfaces options, the updown script is not called any
> > more.
> I tested this (test basic-pluto-01 converted to protostack=mast) and it
> 
> seems to work for me. The logs show:
> | executing spdadd-client: 2>&1 PLUTO_MY_REF=3 PLUTO_PEER_REF=1
> 
> PLUTO_SAREF_TRACKING=yes PLUTO_VERB='spdadd-client' PLUTO_VERSION='2.0'
> PLUTO_CONNECTION='westnet-eastnet' PLUTO_INTERFACE='mast0'
> PLUTO_NEXT_HOP='192.1.2.23' PLUTO_ME='192.1.2.45' PLUTO_MY_ID='@west'
> PLUTO_MY_CLIENT='192.0.1.0/24' PLUTO_MY_CLIENT_NET='192.0.1.0'
> PLUTO_MY_CLIENT_MASK='255.255.255.0' PLUTO_MY_PORT='0'
> PLUTO_MY_PROTOCOL='0' PLUTO_SA_REQID='16388' PLUTO_SA_TYPE='ESP'
> PLUTO_PEER='192.1.2.23' PLUTO_PEER_ID='@east'
> PLUTO_PEER_CLIENT='192.0.2.0/24' PLUTO_PEER_CLIENT_NET='192.0.2.0'
> PLUTO_PEER_CLIENT_MASK='255.255.255.0' PLUTO_PEER_PORT='0'
> PLUTO_PEER_PROTOCOL='0' PLUTO_PEER_CA='' PLUTO_STACK='mast'
> PLUTO_ADDTIME='0'
> PLUTO_CONN_POLICY='RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_
> FRAG_ALLOW' PLUTO_CONN_ADDRFAMILY='ipv4' XAUTH_FAILED=0
> PLUTO_IS_PEER_CISCO='0' PLUTO_PEER_DNS_INFO='' PLUTO_PEER_DOMAIN_INFO=''
> PLUTO_PEER_BANNER='' PLUTO_NM_CONFIGURED='0' ipsec _updown

It seems to work for klips. See the logs:

| install_ipsec_sa() for #4: outbound only
| route owner of "test"[2] 192.168.56.101 unrouted: NULL; eroute owner: NULL
| could_route called for test (kind=CK_INSTANCE)
| sr for #4: unrouted
| route owner of "test"[2] 192.168.56.101 unrouted: NULL; eroute owner: NULL
| route_and_eroute with c: test (next: none) ero:null esr:{(nil)} ro:null 
rosr:{(nil)} and state: 4
| eroute_connection add eroute 192.168.56.102/32:0 --0-> 192.168.56.101/32:0 
=> esp.3fe858d at 192.168.56.101 (raw_eroute)
| pfkey_lib_debug:pfkey_msg_hdr_build:
(...)
| pfkey_lib_debug:pfkey_extensions_free:Free extension 24 (24)
| raw_eroute result=1
| command executing up-host
| executing up-host: 2>&1 PLUTO_VERB='up-host' PLUTO_VERSION='2.0' 
PLUTO_CONNECTION='test' PLUTO_INTERFACE='ipsec0' 
PLUTO_NEXT_HOP='192.168.56.101' PLUTO_ME='192.168.56.102' 
PLUTO_MY_ID='192.168.56.102' PLUTO_MY_CLIENT='192.168.56.102/32' 
PLUTO_MY_CLIENT_NET='192.168.56.102' PLUTO_MY_CLIENT_MASK='255.255.255.255' 
PLUTO_MY_PORT='0' PLUTO_MY_PROTOCOL='0' PLUTO_SA_REQID='16388' 
PLUTO_SA_TYPE='ESP' PLUTO_PEER='192.168.56.101' PLUTO_PEER_ID='192.168.56.101' 
PLUTO_PEER_CLIENT='192.168.56.101/32' PLUTO_PEER_CLIENT_NET='192.168.56.101' 
PLUTO_PEER_CLIENT_MASK='255.255.255.255' PLUTO_PEER_PORT='0' 
PLUTO_PEER_PROTOCOL='0' PLUTO_PEER_CA='' PLUTO_STACK='klips' PLUTO_ADDTIME='0' 
PLUTO_CONN_POLICY='PSK+ENCRYPT+PFS+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW' 
PLUTO_CONN_ADDRFAMILY='ipv4' XAUTH_FAILED=0 PLUTO_IS_PEER_CISCO='0' 
PLUTO_PEER_DNS_INFO='' PLUTO_PEER_DOMAIN_INFO='' PLUTO_PEER_BANNER='' 
PLUTO_NM_CONFIGURED='0' 

> "westnet-eastnet" #2: spdadd-client output: ip6tables v1.4.19.1: invalid
> mask `255.255.255.0' specified
> "westnet-eastnet" #2: spdadd-client output: Try `ip6tables -h' or
> 'ip6tables --help' for more information.
> 
> | command executing up-client

But it does not work for mast protostack. The log here:

| install_ipsec_sa() for #2: outbound only
| route owner of "test"[1] 192.168.56.101 unrouted: NULL; eroute owner: NULL
| could_route called for test (kind=CK_INSTANCE)
| inI2: instance test[1], setting newest_ipsec_sa to #2 (was #0) 
(spd.eroute=#0)
| complete v1 state transition with STF_OK
"test"[1] 192.168.56.101 #2: transition from state STATE_QUICK_R1 to state 
STATE_QUICK_R2
| deleting event for #2
| inserting event EVENT_SA_REPLACE, timeout in 28530 seconds for #2
| event added after event EVENT_REINIT_SECRET
"test"[1] 192.168.56.101 #2: STATE_QUICK_R2: IPsec SA established transport 
mode {ESP=>0xa137d8ab <0x0d4db3ea xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none 
DPD=passive}
| modecfg pull: noquirk policy:push not-client
| phase 1 is done, looking for phase 2 to unpend
| * processed 0 messages from cryptographic helpers
| next event EVENT_NAT_T_KEEPALIVE in 20 seconds
| next event EVENT_NAT_T_KEEPALIVE in 20 seconds

> Perhaps you can show us a log made with plutodebug=all ?

See the relevant parts of both logs (klips / mast) above.

> Can I ask why you want to use the mast stack? It was mostly to support
> multiple L2TP/Transport connections with NAT, and those deployments are
> best upgraded to IPsec/XAUTH ("Cisco IPsec mode"). The only known client
> not to support IPsec/XAUTH is Windows, for which free clients such as
> the Shrew software client is available that supports it.

Yes. You hit exactly the one use case. 

We have windows OS where we cannot interfere too deeply with the clients 
computer. Especially we have to use what the Windows provides and are not 
allowed to install additional software. Thanks for your help.

Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20141212/cc3dbf92/attachment.sig>