On Fri, 12 Oct 2018, Whit Blauvelt wrote:

I remember with FreeSWAN years back when there needed to be a separate
connection to be able to ping from the server itself as compared to systems
behind it. That's not the current case. But I'm trying to understand this
with Libreswan:

These subnets are all routed out the same connection:

172.16.11.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.12.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.13.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.14.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.15.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.31.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3
172.16.32.0/24 via 123.23.123.23 dev enp2s0f1  src 172.17.10.3

They're all listed in the array of rightsubnets in a conn section of
ipsec.conf.

Do all of thes also include 172.17.10.3 as left or within their
leftsubnet ?

There's a system pingable at .1 of each of those at the other end. All of
those .1s can be pinged from behind the server. But from the server itself
currently 172.16.11.1 and 172.16.15.1 cannot. This is not always the case.
Sometimes they all can be pinged from the server. But it's how it is now,
consistently at present.

I've seen situations where if the traffic was once initiated on the
remote server to your libreswan's subnet, it would from then on work. I
think those are related to proxyarp or some statefull firewall that
allows RELATED traffic but related traffic can only happen from the one
site back to libreswan and not the other way around due to the iptables
rules involved/

Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to