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

Whit Blauvelt whit at transpect.com
Sun Oct 14 16:11:44 UTC 2018


On Sat, Oct 13, 2018 at 07:05:48PM -0400, Paul Wouters wrote:

Appreciate the help, Paul.

> 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 ?

Yes.

> >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/

The iptables side is simply:

iptables -t mangle -A PREROUTING -p 17 --dport 500 -j MARK --set-mark 1 # udp/isakmp
iptables -t mangle -A PREROUTING -p 50 -j MARK --set-mark 1 # esp
iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT
iptables -t filter -A FORWARD -m mark --mark 1 -j ACCEPT
iptables -t filter -A OUTPUT -m mark --mark 1 -j ACCEPT

Nothing about ESTABLISHED, RELATED for this traffic. And everything
subsequently dropped is logged. I haven't found anything logged as blocked
that within the LAN IP ranges at either end -- or anything being logged at
all as the traffic fails. 

I went to test whether pinging from the far side would get the 172.16.11.1
address pingable from this one, but now find that since I was looking at
this Friday both subnets I couldn't reach directly from the firewall then
are now reachable from it. All remote subnets were at the same time pingable
from behind the firewall Friday, and remain so today. The other side
initiating communications to behind the firewall certainly happens -- we've
got many systems either side that normally exchange traffic. But nothing on
the other side except a single Nagios server addresses any traffic to the
firewall here as such, at its own IP.

I'm going to try some restarts of the firewall to see if they can get it
into a bad situation again, to try the "ping from other end" cure then. I'll
also check for proxyarp -- don't believe that's on anywhere, but you're
right, that's worth being sure of.

Whit


More information about the Swan mailing list