[Openswan Users] Amazon EC2: Can't avoid 10.0.0.0/8

Wed Jun 6 13:46:36 EDT 2012

Hi Ryan,

Sorry if I'm being dense (networking is definitely not my strong point),
but I have a couple of questions:

1. I've read many threads on this list where folks pointed out that you
should almost never need to mess with adding routes yourself, because if
you configured your connection correctly, OpenSwan would do that for you.
Is there a good rule of thumb for when this isn't true? In this case, don't
the leftnexthop and leftsourceip settings both tweak the way OpenSwan sets
up routes to the rightsubnet?

Is the problem that both Amazon and OpenSwan are using a network range
route and Amazon's is taking precedence, but a host route I add myself will
take precedence over them both?

2. When I have the connection up, I can run:

$ sudo ip -s route get 10.10.1.13/32
10.10.1.13 dev eth0  src 184.72.237.166
    cache  users 1 mtu 1500 advmss 1460 hoplimit 64

With my limited understanding, this route (to the desired remote LDAP
server), should be going through the default gateway on eth0 and should
have a src IP of 184.72.237.166 (my elastic IP address). Isn't this what I
want?

Thanks so much.
-Wes

sudo ip route add 10.10.1.13 via <rightside_ip> src <left_elastic_ip>

On Wed, Jun 6, 2012 at 1:02 PM, Ryan Whelan <rcwhelan at gmail.com> wrote:

> If you add a host route, it should take precedence over a network range
> route.
>
> On Wed, Jun 6, 2012 at 12:51 PM, Wes Winham <wes at policystat.com> wrote:
> > Hello,
> >
> > I'm attempting to follow the tutorial
> > at: https://www.openswan.org/projects/openswan/wiki/Amazon_EC2_example
> >
> > I have an Ubuntu 10.04 ec2 instance that needs to be able to access an
> LDAP
> > server on a remote network behind a Cisco ASA. The problem is that the
> LDAP
> > server has the IP 10.10.1.13, which is in the block that EC2 uses.
> >
> > There's a note in the tutorial "If it is via port forward, avoid 10/8
> that
> > Amazon uses". Any suggestions for what needs to be done if the other side
> > does use that block?
> >
> > Right now, the tunnel is successfully established:
> >
> > $ sudo ipsec auto --up apd
> > 117 "apd" #3: STATE_QUICK_I1: initiate
> > 004 "apd" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
> > {ESP/NAT=>0x4041650d <0xa7665556 xfrm=3DES_0-HMAC_MD5 NATOA=none
> NATD=none
> > DPD=none}
> >
> > The problem is that pings to 10.10.1.13 aren't reaching the other end.
> From
> > the EC2 instance, I run:
> >
> > $ ping 10.1.1.13
> >
> > All of the packets are lost, even though that box is in fact configured
> to
> > respond to ping (same results with nmap to the LDAP port). I then monitor
> > with:
> >
> > $ sudo tcpdump -n host 10.1.1.13
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 12:40:07.212436 IP 10.243.79.134 > 10.1.1.13: ICMP echo request, id
> 62815,
> > seq 1, length 64
> > 12:40:08.229371 IP 10.243.79.134 > 10.1.1.13: ICMP echo request, id
> 62815,
> > seq 2, length 64
> >
> > My IPSec verify looks good I think:
> >
> > $ sudo ipsec verify
> > Checking your system to see if IPsec got installed and started correctly:
> > Version check and ipsec on-path                             [OK]
> > Linux Openswan U2.6.23/K2.6.32-318-ec2 (netkey)
> > Checking for IPsec support in kernel                         [OK]
> > NETKEY detected, testing for disabled ICMP send_redirects   [OK]
> > NETKEY detected, testing for disabled ICMP accept_redirects [OK]
> > Checking for RSA private key (/etc/ipsec.secrets)           [OK]
> > Checking that pluto is running                               [OK]
> > Pluto listening for IKE on udp 500                           [OK]
> > Pluto listening for NAT-T on udp 4500                       [OK]
> > Two or more interfaces found, checking IP forwarding         [OK]
> > Checking NAT and MASQUERADEing                               [N/A]
> > Checking for 'ip' command                                   [OK]
> > Checking for 'iptables' command                             [OK]
> > Opportunistic Encryption Support                             [DISABLED]
> >
> > Any hints on how to solve the 10.0.0.0/8 thing or maybe some additional
> > debugging tips I could try?
> >
> > Also, if anyone else is trying to follow that tutorial using Ubuntu
> 10.04,
> > this might help:
> > https://gist.github.com/2871257
> >
> > I wrote up detailed instructions for Ubuntu 10.04 (which needs network
> > parameters to be tuned) and a subnet to subnet connection specifically.
> >
> > Thanks
> > -Wes
> >
> > --
> > Wes Winham, Product Development
> > PolicyStat, LLC | mobile: 405.320.9379 | desk: 317.644.1296 x1105
> > schedule: http://tungle.me/weswinham
> >
> > _______________________________________________
> > Users at lists.openswan.org
> > https://lists.openswan.org/mailman/listinfo/users
> > Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> > Building and Integrating Virtual Private Networks with Openswan:
> > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> >
>

-- 
*Wes Winham, Product Development*
PolicyStat, LLC | mobile: 405.320.9379 | desk: 317.644.1296 x1105
schedule: http://tungle.me/weswinham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openswan.org/pipermail/users/attachments/20120606/17c5e20e/attachment-0001.html>