[strongSwan] Routing between two remote sites

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Tue Jan 25 20:55:57 CET 2022


Hello,

on your hub, you need to declare the other spokes' subnets to be local for a specific spoke.
So formulated out for hub H, and spokes ABC:

Config on hub H:
conn for spoke A:
- local BCH
- remote A
conn for spoke B:
- local ACH
- remote B
conn for spoke C:
- local ABH
- remote C

Config on spoke A:
conn for hub H:
- local A
- remote BCH

Config on spoke B:
conn for hub H:
- local B
- remote ACH

Config on spoke C:
conn for hub H:
- local C
- remote ABH


I hope this helps. :)

Kind regards
Noel

Am 25.01.22 um 16:35 schrieb VTwin Farriers:
> yes, that was a cut-and-paste error into my browser email window. I have the same local_ts=10.64.0.0/16,10.128.0.0/16 and remote_ts=10.64.0.0/16,10.128.0.0/16 in my respective files. unfortunately i'm working remotely over a slow internet connection with only browser-based email so cut and paste is flakey.
> 
>> On January 25, 2022 at 10:21 AM Michael Schwartzkopff <ms at sys4.de> wrote:
>>
>>
>> On 25.01.22 16:07, VTwin Farriers wrote:
>>> Thank you all for your responses.
>>>
>>> I have the same local_ts/remote_ts values on my East and Central swanctl.conf files. I would think this should work but for some reason I get the TS_UNACCEPTABLE error. Removing "10.128.0.0/24" from the swanctl.conf files on east and central will then work.
>>>
>>>
>>> swanctl.conf (East)
>>>
>>> connections {
>>> eastcentral {
>>> version=2
>>> local_addrs=a.b.c.d
>>> proposals=aes256-sha1-modp1024, default
>>> local-0 {
>>> auth = psk
>>> }
>>> remote-0 {
>>> auth = psk
>>> }
>>> remote_addrs=w.x.y.z
>>> children {
>>> eastcentral {
>>> esp_proposals=aes256-sha1, default
>>> dpd_action=restart
>>> remote_ts=10.64.0.0/16,10.128.0.0/64
>>> local_ts=10.0.0.0/16
>>> }
>>> }
>>> }
>>> }
>>>
>>>
>>> swanctl.conf (Central):
>>>
>>> connections {
>>> centraleast {
>>> version=2
>>> local_addrs=w.x.y.z
>>> proposals=aes256-sha1-modp1024, default
>>> local-0 {
>>> auth = psk
>>> }
>>> remote-0 {
>>> auth = psk
>>> }
>>> remote_addrs=a.b.c.d
>>> children {
>>> centraleast {
>>> esp_proposals=aes256-sha1, default
>>> dpd_action=restart
>>> remote_ts=10.0.0.0/16
>>> local_ts=10.64.0.0/16,10.128.0.0/16
>>> }
>>> }
>>> }
>>> }
>>>
>>>
>>>
>>> [root at EastRouter swanctl]# strongswan up eastcentral
>>> initiating IKE_SA eastcentral[1] to w.x.y.z
>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>>> sending packet: from a.b.c.d[500] to w.x.y.z[500] (1204 bytes)
>>> received packet: from w.x.y.z[500] to a.b.c.d[500] (344 bytes)
>>> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
>>> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>> remote host is behind NAT
>>> no IDi configured, fall back on IP address
>>> authentication of 'a.b.c.d' (myself) with pre-shared key
>>> establishing CHILD_SA eastcentral{1}
>>> generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
>>> sending packet: from a.b.c.d[4500] to w.x.y.z[4500] (668 bytes)
>>> received packet: from w.x.y.z[4500] to a.b.c.d[4500] (220 bytes)
>>> parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
>>> authentication of 'w.x.y.z' with pre-shared key successful
>>> IKE_SA eastcentral[1] established between a.b.c.d[a.b.c.d]...w.x.y.z[w.x.y.z]
>>> scheduling rekeying in 13393s
>>> maximum IKE_SA lifetime 14833s
>>> received TS_UNACCEPTABLE notify, no CHILD_SA built
>>> failed to establish CHILD_SA, keeping IKE_SA
>>> peer supports MOBIKE
>>> establishing connection 'eastcentral' failed
>>
>>
>> In the config on the east router your have:
>> remote_ts=10.64.0.0/16,10.128.0.0/64
>>
>>
>> On the central gateway you have:
>>
>> local_ts=10.64.0.0/16,10.128.0.0/16
>>
>>
>>
>> The subnets for 10.128.0.0 do not fit. Especially since /64 does not
>> make sense in a legacy IP network.
>>
>>
>> Mit freundlichen Grüßen,
>>
>> -- 
>>
>> [*] sys4 AG
>>    
>> https://sys4.de, +49 (89) 30 90 46 64
>> Schleißheimer Straße 26/MG,80333 München
>>    
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
>> Aufsichtsratsvorsitzender: Florian Kirstein
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220125/9f5b7fe3/attachment.sig>


More information about the Users mailing list