[strongSwan] Is there good documentation on Netfilter/iptables strategies with strongSwan?

[Whit Blauvelt]

Hi,

I find discussion three years ago in this list on using iptables marks with
strongSwan, and see suggestions there may be some of that it does
automatically in the background. There was discussion three years back about
researching different advanced methods. If it reached a clear conclusion, I
haven't found it.

I have also found a partial discussion elsewhere of possible conflicts
between strongSwan's methods and the marking techniques used by FireHOL, but
again without full resolution or a final summary document. In my own case
I'm finding FireHOL and its link-balancer utility invaluable.

I'm also not yet routing correctly to the subnets behind a system with those
on one end and the subnets behind one on AWS on the other -- where the AWS
instance has a slight complication in that it's got several interfaces, one
on a VPC, the other -- which strongSwan is connecting to -- not.

A few years back, when running openswan, I'd set up iptables like this:

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

Worked well there. Obviously it's not a good formula for strongSwan (I've of
course tried it). Can someone please point me to either a good background
discussion or a good current set of examples showing how to get strongSwan
and Netfilter working correctly together?

I realize strongSwan works on platforms other than Linux, so documenting
Netfilter or pf or whatever isn't central to its mission. Still, in an ideal
world its documents will expand to include theory and recipes for the
various firewalls it is commonly used with.

Best,
Whit

[Eric Germann]

First off in AWS, if you’re going to be a router, have you disabled “Source/Destination Check” (or something to that effect) in the instance properties? If not, the instance will work across the tunnel, but you won’t be able to route through it.

EKG

Post by Whit Blauvelt
Hi,
I find discussion three years ago in this list on using iptables marks with
strongSwan, and see suggestions there may be some of that it does
automatically in the background. There was discussion three years back about
researching different advanced methods. If it reached a clear conclusion, I
haven't found it.
I have also found a partial discussion elsewhere of possible conflicts
between strongSwan's methods and the marking techniques used by FireHOL, but
again without full resolution or a final summary document. In my own case
I'm finding FireHOL and its link-balancer utility invaluable.
I'm also not yet routing correctly to the subnets behind a system with those
on one end and the subnets behind one on AWS on the other -- where the AWS
instance has a slight complication in that it's got several interfaces, one
on a VPC, the other -- which strongSwan is connecting to -- not.
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
Worked well there. Obviously it's not a good formula for strongSwan (I've of
course tried it). Can someone please point me to either a good background
discussion or a good current set of examples showing how to get strongSwan
and Netfilter working correctly together?
I realize strongSwan works on platforms other than Linux, so documenting
Netfilter or pf or whatever isn't central to its mission. Still, in an ideal
world its documents will expand to include theory and recipes for the
various firewalls it is commonly used with.
Best,
Whit

[Whit Blauvelt]

First off in AWS, if you’re going to be a router, have you disabled
“Source/Destination Check” (or something to that effect) in the instance
properties? If not, the instance will work across the tunnel, but you
won’t be able to route through it.

Thanks Eric. I had already done that; it has been disabled this whole time.

I've also done the other obvious stuff, such as turning of rp_filter,
turning on forwarding....

Hopefully someone can point me in the right direction to answer my Netfilter
questions.

Best,
Whit

[Whit Blauvelt]

A small bit of evidence on where I'm stuck:

Both ends can ping through the tunnel each other on any of their several
IPs.

When the non-Amazon end pings addresses behind the AWS instance, those pings
make it to the AwS instance. When the AWS instance pings addresses behind
the non-Amazon end, the pings don't make it that far.

So something's screwed up with the routing out of Amazon. I do have a
routing table set up in AWS to send traffic for the office-side subnets to
the interface ID of the strongSwan instance.

So this route, to an IP on the strongSwan box, works for pings:

# ip ro get 172.17.10.3
172.17.10.3 via 172.18.30.1 dev eth0 src 172.18.30.93
cache

This, to another IP on that same subnet, does not get to 172.17.10.3 as it
should:

# ip ro get 172.17.10.2
172.17.10.2 via 172.18.30.1 dev eth0 src 172.18.30.93
cache

However it routes to the public just fine:

# ip ro get 8.8.8.8
8.8.8.8 via 172.18.30.1 dev eth0 src 172.18.30.93
cache

I don't really know what Amazon has at 172.18.30.1, nor what's required to
clear that in the right way. Perhaps it's not Netfilter at all, but just the
opaque operations of AWS that block me.

Thanks,
Whit

[Eric Germann]

Do your SG’s on the AWS side allow the remote IP’s inbound to the target IP’s on the AWS side?

Also, we set reqid to a value on the conn block in ipsec.conf (although I don’t think it’s necessarily required if you’re OK with random reqid’s).

In /etc/sysconfig/iptables, we then set:

-A FORWARD -m comment --comment "Process inbound IPsec traffic"
-A FORWARD -s 100.126.4.208/28 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT

-A FORWARD -m comment --comment "Process outbound IPsec traffic"
-A FORWARD -d 100.126.4.208/28 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT


If we don’t set reqid’s, we can get away without specifying them and have something along the lines of

-A FORWARD -s 100.126.4.208/28 -j ACCEPT
-A FORWARD -d 100.125.4.208/28 -j ACCEPT

N.B. you’ll need forward stanzas for your VPC network block also.

Also, our routers are Centos 6/7

Email me off list if you want to get deeper. We have hundreds to tunnels on AWS using StrongSwan.

EKG

Post by Whit Blauvelt
Both ends can ping through the tunnel each other on any of their several
IPs.
When the non-Amazon end pings addresses behind the AWS instance, those pings
make it to the AwS instance. When the AWS instance pings addresses behind
the non-Amazon end, the pings don't make it that far.
So something's screwed up with the routing out of Amazon. I do have a
routing table set up in AWS to send traffic for the office-side subnets to
the interface ID of the strongSwan instance.
# ip ro get 172.17.10.3
172.17.10.3 via 172.18.30.1 dev eth0 src 172.18.30.93
cache
This, to another IP on that same subnet, does not get to 172.17.10.3 as it
# ip ro get 172.17.10.2
172.17.10.2 via 172.18.30.1 dev eth0 src 172.18.30.93
cache
# ip ro get 8.8.8.8
8.8.8.8 via 172.18.30.1 dev eth0 src 172.18.30.93
cache
I don't really know what Amazon has at 172.18.30.1, nor what's required to
clear that in the right way. Perhaps it's not Netfilter at all, but just the
opaque operations of AWS that block me.
Thanks,
Whit