[Swan] Bringing up strongSwan+Libreswan transport connection

Pavel Volkov sailor at lists.xtsubasa.org
Tue Oct 1 06:45:16 UTC 2019


On вторник, 1 октября 2019 г. 05:28:32 MSK, Paul Wouters wrote:
> Yes, if the libreswan server only has that IP because it is behind NAT,
> then you can only use that IP as an IP range. If you want the "public
> IP" of the NAT machine to be the IP that the strongswan machine talks
> to, then you have to add that IP as alias on the libreswan machine and
> use rightsubnet=xxx.xxx.94.200/32
>
> So if you current solution does not do what you want, then perhaps try
> to explain what IP ranges you want to connect with IPsec.

No, my current solution works as intended.
Only trying to understand if I'm not doing it wrong. I only wish for a 
secure connection between two hosts (one behind NAT), nothing more.

I thought using rightsubnet= was strange here because the docs say:
leftsubnet
  private subnet behind the left participant

and it's not "behind" in my scenario, it is participant's own address.

If I change the configs into what you proposed, i. e.:
1. remove rightsubnet=192.168.1.2 in strongSwan
2. add rightsubnet=xxx.xxx.94.200/32 in Libreswan

then connection breaks: IKE handshake still succeeds, but encrypted traffic 
doesn't flow.

I think it's because the policy changed on Libreswan side. Before breaking 
it was:

src 192.168.1.2/32 dst xxx.xxx.149.202/32 
        dir out priority 1040351 
        tmpl src 192.168.1.2 dst xxx.xxx.149.202
                proto esp reqid 16389 mode tunnel

Looks legit to me.

Now after the change above:

src xxx.xxx.94.200/32 dst xxx.xxx.149.202/32 
        dir out priority 1040351 
        tmpl src 192.168.1.2 dst xxx.xxx.149.202
                proto esp reqid 16389 mode tunnel

Now source address is not our local.
Still, there's "tmpl src 192.168.1.2", I'm not sure if the kernel matches 
packets against it.

According to tcpdump outgoing pings go unencrypted and the other side 
ignores them.


More information about the Swan mailing list