[strongSwan] traffic beyond initiator yes, but no between initiator & server

[Noel Kuntze]

Hi Lejeczek,

> I do not see, not on the server nor on initiator, any tun
> devices created, unless an 'ipsec0' is such one iface. It's
> the only iface I see made by strongswan's libipsec.

Device names are arbitrary and thus not useful for identifying the type of interface.
the ipsec0 device is created by kernel-libipsec and is the one you should use.

You can use `ip -d l` to see the type of a network device.

>>
>>>         mode = pass
> I've tried all modes available.

That doesn't make it work though. Don't set it. libipsec only supports tunnel mode SAs anyway.


> If I do not have a iface on the server with 10.3.9.0/24 then
> roadwarrior fails with:
> ...
> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
> [IKE] failed to establish CHILD_SA, keeping IKE_SA
> initiate failed: establishing CHILD_SA 'to-tinyionos' failed
> 
> Maybe I should add, in case there is something very
> different there, I'm on Centos 8 and libipsec I mention is:
> strongswan-libipsec-5.8.2-5.el8.x86_64
> 
> What's is not 'normal' in my roadwarrior config?
> 
> many thanks, L.
> 

I now see that you probably don't want to use a roadwarrior config but a site-to-site config.
You're just confused. Which is the reason for this weird config.
I guess you want to connect the two sides using libipsec? 

libipsec is used for roadwarrior type scenarios and thus where the negotiated local_ts is required to contain a local IP after
any VIPs were assigned. I don't know how strongSwan behaves if you make both sides request VIPs, but only configure a pool on one.
I assume negotiation should actually fail because the side without the pool doesn't respond (to the configuration payload (CP) request of the other side)
with a VIP.

>> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built

The other side's log will tell you why that notify was sent.

If you actually need to use libispec on both sides, then assign the two sides static IPs in their LAN range using CPs and set remote_ts and local_ts to the corresponding host's networks.
That way the VIP will be inside the TSs and negotiation will succeed.

You probably don't want to use libipsec though but XFRM in policy mode, or configure a route based IPsec tunnel.

What do you actually want to do? 

Kind regards

Noel

Am 05.11.20 um 21:46 schrieb lejeczek:
> 
> 
> On 05/11/2020 17:19, Noel Kuntze wrote:
>> Hello Lejeczek,
>>
>> kernel-libipsec (which is required to be loaded for libipsec to be usable) creates a tun interface itself. You can not prescribe it to use one.
> I do not see, not on the server nor on initiator, any tun
> devices created, unless an 'ipsec0' is such one iface. It's
> the only iface I see made by strongswan's libipsec.
>>
>>>         mode = pass
> I've tried all modes available.
>> That disables all IPsec processing for traffic that matches the policies. You probably don't want to do that.
>>
>>> 1) Obvious - how to make it work?
>> Completely different from what you configured. Just use a normal roadwarrior config.
> If I do not have a iface on the server with 10.3.9.0/24 then
> roadwarrior fails with:
> ...
> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
> [IKE] failed to establish CHILD_SA, keeping IKE_SA
> initiate failed: establishing CHILD_SA 'to-tinyionos' failed
> 
> Maybe I should add, in case there is something very
> different there, I'm on Centos 8 and libipsec I mention is:
> strongswan-libipsec-5.8.2-5.el8.x86_64
> 
> What's is not 'normal' in my roadwarrior config?
> 
> many thanks, L.
> 
>>
>> Kind regards
>>
>> Noel
>>
>> Am 05.11.20 um 17:45 schrieb lejeczek:
>>> Hi guys
>>>
>>> To start I should say I'm trying this with libipsec.
>>>
>>> I have an initiator with local 10.3.1.0/24 and a following
>>> config:
>>>
>>>
>>> connections {
>>>   to-tinyionos {
>>>     version = 2
>>>     remote_addrs = "A.B.C.D"
>>>     vips = "0.0.0.0"
>>>     local {
>>>       auth = pubkey
>>>       certs = "my.cert.der"
>>>     }
>>>     remote {
>>>       certs = "server.cert.der"
>>>     }
>>>     children {
>>>       to-tinyionos {
>>>         mark_in = %unique
>>>         mark_out = %unique
>>>         remote_ts = "10.3.9.0/24"
>>>         local_ts = "10.3.1.0/24"
>>>         #mode = "tunnel"
>>>         mode = pass
>>>       }
>>>     }
>>>   }
>>> }
>>>
>>> and there I have a server with a tun iface:
>>>
>>> 17: forswan: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu
>>> 1500 qdisc fq_codel state DOWN group default qlen 500
>>>     link/none
>>>     inet 10.3.9.1/24 brd 10.3.9.255 scope global
>>> noprefixroute forswan
>>>        valid_lft forever preferred_lft forever
>>>
>>> and server config, connection part:
>>>
>>>
>>>   fenbox {
>>>     version = 2
>>>     pools = "myclient"
>>>     vips = "0.0.0.0"
>>>     remote {
>>>       auth = "pubkey"
>>>       id = "O=client, CN=tiny.client"
>>>     }
>>>     children {
>>>       fenbox {
>>>         mark_in = %unique
>>>         mark_out = %unique
>>>         local_ts = "10.3.9.0/24"
>>>         remote_ts = "10.3.1.0/24"
>>>         #mode = transport
>>>         #mode = "tunnel"
>>>         mode = pass
>>>       }
>>>     }
>>>   }
>>>
>>>
>>> What I'd like to get, which I'm not for some reason, is:
>>> - to access IP of 10.3.9.0/24 subnet.
>>> From the server I can get to initiator's 10.3.1.0/24, but
>>> the server with 10.3.9.1 on tun iface cannot get to
>>> initiator's assigned 10.3.9.254.
>>> I have two questions:
>>> 1) Obvious - how to make it work?
>>> 2) I notice that initiators gets an IP: 10.3.9.254/32 - is
>>> this that subnet because how libipsec works and if yes then
>>> can it be controlled and changed?
>>>
>>> many thanks, L.
>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20201106/03672687/attachment.sig>