[strongSwan] Fun with AWS, primary connection there but can't route out to remote subnets
ekgermann at semperen.com
Sat Sep 23 21:33:11 CEST 2017
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.
> On Sep 23, 2017, at 3:24 PM, Whit Blauvelt <whit at transpect.com> wrote:
> A small bit of evidence on where I'm stuck:
> Both ends can ping through the tunnel each other on any of their several
> 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
> 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
> However it routes to the public just fine:
> # ip ro get 22.214.171.124
> 126.96.36.199 via 172.18.30.1 dev eth0 src 172.18.30.93
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3705 bytes
Desc: not available
More information about the Users