[Swan] Divergent results for whether a subnet is pingable from server and behind it

[Whit Blauvelt]

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.

They're all treated identically by iptables. 

ipsec whack --status gives results that look the same for all.

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. 

It's not that the server itself needs to be sending traffic to each of the
subnets generally. But it would be good to have a test running on the server
to be sure they're all up, so ipsec can be restarted when/if they fail. Yet
it's not desirable to restart ipsec on the server if it's just the server's
point of view that one or more is bad from.

Obviously I could run the test from another system, and send commands by ssh
to the server when appropriate to address a revealed problem. Still, that
seems like a less reliable scheme. 

It's a Cisco ASA on the other end, not under my direct admin. 

Any ideas on what would account for this inconsistency in performance?

Thanks,
Whit