[strongSwan] Fun with AWS, primary connection there but can't route out to remote subnets

[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



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3705 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170923/4504132f/attachment.bin>