[strongSwan] Routing between two remote sites

[Noel Kuntze]

Hello,

Please use swanctl and swanctl.conf instead of ipsec and ipsec.conf.
That enables you to use XFRM interfaces which are the best way to connect sites.
By default, unless you set up VTIs (not recommended), GRE tunnels (not recommended) or XFRM interfaces (recommended), there are no tunnel interfaces but only policies that are applied globally (within the network namespace of course).

The iptables rules/nftables rules, specifically NAT rules also apply to traffic that is supposed to be tunneled because the criteria the NAT rules ususally have do not take into account if there are XFRM policies for the packets or not.

The wiki again gives some guidance on that topic[1].

Kind regards
Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems

Am 27.01.22 um 22:10 schrieb VTwin Farriers:
>> I'm sorry to say this but that was unnecessary because you can disable the plugins in the configuration. You do not need to recompile anything. 
>
> Well it was a learning experience for me :)
>
> I looked in the stock EPEL configuration directories created for strongswan. /etc/strongswan/strongswan.d/charon/kernel-libipsec.conf had "load=yes".
>
> I changed this to "load=no" on both systems and restarted strongswan
>
> Now I get:
>
> [root at CentralRouter]# strongswan up CentralEast
> establishing CHILD_SA CentralEast{8}
> generating CREATE_CHILD_SA request 0 [ SA No TSi TSr ]
> sending packet: from WW.XX.YY.ZZ[4500] to AA.BB.CC.DD[4500] (620 bytes)
> received packet: from AA.BB.CC.DD[4500] to WW.XX.YY.ZZ[4500] (476 bytes)
> parsed CREATE_CHILD_SA response 0 [ SA No TSi TSr ]
> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
> CHILD_SA CentralEast{8} established with SPIs cd247e35_i fef555a5_o and TS 10.64.0.0/16,10.128.0.0 === 10.0.0.0/16
> connection 'CentralEast' established successfully
>
>
> Yeaaaaaaaaa!
>
> Uh... not so fast :(
>
>
> [root at CentralRouter]# ping 10.0.0.1
>
> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
> ^C
> --- 10.0.0.1 ping statistics ---
> 10 packets transmitted, 0 received, 100% packet loss, time 3052ms
>
>
> [root at CentralRouter]# strongswan status
> Security Associations (4 up, 0 connecting):
> CentralEast[9]: ESTABLISHED 7 minutes ago, WW.XX.YY.ZZ[WW.XX.YY.ZZ]...AA.BB.CC.DD[AA.BB.CC.DD]
> CentralEast{7}: INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: cdc46ed8_i fd5e2ca8_o
> CentralEast{7}: 10.64.0.0/16,10.128.0.0/24 === 10.0.0.0/16
>
> however,
>
> [root at CentralRouter]# ip route show match 10.0.0.1
> default via WW.XX.YY.ZZ dev Internet proto static metric 351
>
> [root at CentralRouter]# ip route show table 220
> 10.0.0.0/16 via WW.XX.YY.ZZ dev Internet proto static src 10.64.0.1
>
>
> so it appears the traffic is attempting to route over my regular internet ip link rather than the ipsec tunnel?
>
> Not sure where to go from this point, but thanks for the help so far. Overcame one hurdle but looks like I have another.
>

-------------- 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/20220127/d589cf16/attachment.sig>