[Openswan Users] Request for configuration help for non-trivial AWS VPC OpenSwan Remote User L2TP/IPsec VPN configuration

Michael Crawford michael.crawford at mjcconsulting.com
Fri Aug 30 22:33:46 UTC 2013


Had turned on digest delivery, just switched back, but didn¹t get your
email response. Will reply from your response harvested from the archive

> You can leave out TCP/4500 as the encapsulation happens on UDP/4500 only.


> This is interesting as IIRC Amazon didn't route ESP before.

Not sure on this myself, just trying to get things to work with Openswan
in most common config before I move on to less common variants. I'm
currently coming from behind either an Airport Extreme or Cisco ASA 5505
at home, both with NAT, but both have public outside IPs. I can configure
my ASA to run static identity NAT to a guest / DMZ and attempt to test a
client which would not go through NAT to see if ESP works with that path,
but it's not a near-term priority. I'm more likely to just remove the ESP
traffic pattern, as it's unlikely to see any real-world use.

> Since you use IPsec to only "transport" the L2TP traffic, the leftsubnet
>is meaningless.

OK. That wasn't in the original examples I was using as a starting point,
just something I added to try and see if that helped. It didn't, and I've
removed it.

> Shouldn't the above also include something for IP pro to 50 (ESP)?

You're thinking a bit ahead of me, I would have likely noticed that myself
once I tried to get ESP working. But, as noted above, more likely I'll
remove this, as it's unlikely to be used. Thanks for pointing it out,

> Those are covered by the 10.240.3/24 so you connect to them directly:
> not crossing interfaces on the VPN gateway.

Right. I understood that point. My question was really: How is this set?
That particular CIDR subnet is not defined anywhere in the VPC
configuration or in the openswan, xl2tpd or pop configurations, so I
didn't know how it got there.

I've since learned how (I think), but based on my knowledge on configuring
Cisco devices, I thought the VPN endpoint was where you configured and
specified the tunnel for any clients, so the split-tunnel configuration
was being sent by the VPC end of the VPN, with some default value for the
subnet based on the ppp DHCP range I specified of - 254,
defaulting to a /24 subnet mask. I could not find what program may have
set this or any info about what the default value was if it was not set,
which is the main reason I reached out for help on this. . .

> That's where I'd start debugging this issue.

> First, I'd check on the VPN gateway to see what reaches it from the VPN
> client and if something is transmitted to the destination IP.

> Secondly, I'd check if a machine in the subnet can ping
> the VPN client (or if you see the packets crossing the VPN gateway).

> The routes are configured by the client. It seems like you OS assigns a
> default route to the PPP interface so all you packets should reach the
> VPN gateway.

So this is what I learned after sending my original email on this thread
by some additional Googling - The Mac OS X built-in client does in fact
specify the route by taking the remote pop endpoint (in this case and routing the enclosing /24 network to it via the pop
interface. AFAIK, this route is NOT sent via the openswan end - no routing
information is sent. I'd really love to be wrong here and hear about some
way for openswan/ppp to send the routes available on the VPC end, so that
the client will automatically configure itself to use them.

But, in the meantime, what I discovered is that I can automatically add
the missing routes on the OS X end via a script such as this, in
/etc/ppp/ip-up (mode 0755):
# Add missing routes to L2TP/IPSec connections into AWS VPC
# - Log route changes to existing ppp log
# Parameters:
# - $1 the interface name used by pppd (e.g. ppp3)
# - $2 the tty device name
# - $3 the tty device speed
# - $4 the local IP address for the interface
# - $5 the remote IP address
# - $6 the parameter specified by the 'ipparam' option to pppd

# List VPC CIDR ranges, routes will automatically be added based on these

date=$(date '+%a %b %d %H:%M:%S %Y')

# Matching logic assumes one VPC remote gateway IP per /16 network
# - matches first 16 bits of gateway_ip to same on VPC CIDR to pick route
to add
case "${vpn_gateway_ip%*.*.*}" in
  ${vpc1_cidr%*.*.*/*} )
    echo "$date : route add -net $vpc1_cidr -interface $1" >>
    /sbin/route add -net $vpc1_cidr -interface $1

  ${vpc2_cidr%*.*.*/*} )
    echo "$date : route add -net $vpc2_cidr -interface $1" >>
    /sbin/route add -net $vpc2_cidr -interface $1

  ${vpc3_cidr%*.*.*/*} )
    echo "$date : route add -net $vpc3_cidr -interface $1" >>
    /sbin/route add -net $vpc3_cidr -interface $1

  ${vpc4_cidr%*.*.*/*} )
    echo "$date : route add -net $vpc4_cidr -interface $1" >>
    /sbin/route add -net $vpc4_cidr -interface $1

  * )
    echo "$date : no routes added" >> /var/log/ppp.log

exit 0

This has now solved this last issue when I'm coming in via OS X. I haven't
tested what IOS on my iPad does. I previously tested that this works from
the "prompt" ssh app to instances in the 10.240.3/24 range, haven't tried
this yet with hosts outside of that range, as I just got this working.
Because the solution above requires custom config on the client, I don't
think it will work on IOS, as I don¹t have the same ability to make
similar changes there. But, they may set a different subnet size for the

Not that big a deal, this was always meant as an emergency workaround
method. But it would be nice if the openswan/ppp end could send some type
of hint on the remote end subnet size for IOS, if it's designed to accept
and use such a hint. That's the remaining question on this thread. . .


More information about the Users mailing list