[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