[Openswan Users] Connecting to AWS with BGP routing

Amos Shapira amos.shapira at gmail.com
Sun Feb 21 19:02:36 EST 2016


Thanks very much Daniel,

I got the IPSec tunnel up alright (with "src/dest check" turned off,
Security Groups letting through the right traffic etc).
I can route traffic directly between the VPC which is directly behind the
Amazon Virtual GW and the VPC to which the EC2 instance belongs.
It's the BGP part that doesn't work.

I CAN NOT ping the hosts on addresses 169.254.44.122 or 169.254.44.121, I
suspect this could be the main symptom of something I'm missing. These
addresses are not configured on any interface.

The link you provide is circa 2010 and uses Racoon for the IPsec part. I
see that it mentions "ip a a inside-address", is this something I need to
do when using OpenSwan too?

There isn't much advantage for JunOS in my case since I'm not familiar with
it, on the other hand, I noticed that there is a "Vyatta" format option in
the us-east-1 region (not in the ap-southeast-2 region), which might make
it easier to bring up a VyOS AMI, feed it the configuration from the VGW
as-is and see how it translates it to ipsec.conf and bgpd.conf files. I
intend to try that.

Would you be able to share your ipsec.conf and bgpd.conf (with specific
details obscured), and how they map from the configuration downloaded from
the VGW?

Thanks for the tip about the MSS size. I haven't had issues with this so
far but I'll watch out for it.

--Amos

On 22 February 2016 at 04:18, Daniel Cave <dan.cave at me.com> wrote:

> Hi Amos.. i meant to reply to you last week when i saw your mail but for
> reasons i couldn't.
>
> I wanted to reply because I have recently done this but using a Linux
> based firewall/router called VyOS to specifically connect to a VPC using
> Amazon's VPN device ,using BGP routing
>
> Important things you have to do/need to know.
>
> 1. the MSS must be clamped to 1436 bytes, otherwise nothing will work -
> the tunnel wont come up properly,
> you wont be able to pass traffic between the two networks and your BGP
> wont work either.
>
> 2. you dont say in your posts previously but can you ping each host  (ie
> host to AWS openswan box using the 169.254.x.x ip's ? between your two
> VPC's)
>
> If you have the correct icmp security group rules and you've disabled
> 'check source address' in your networking adapter on the instances, you
> should be able to.
>
> once that's done, you should try initiating the BGP configuration again.
> Typically I have noticed it takes between 30 seconds and a minute or so
> before your remote peer (thats the 169.254.44.121 ) picks up anything - you
> should be able to query quagga directly by a ttysh and issue a 'show ip bgp
> summary' and 'show ip bgp routes'.    Personally I used VyOS because
> everything is contained and setup in that and the config syntax is very
> JunOS/cisco like.
>
> I also noticed that your quagga daemon config you've not setup your router
> id, in the config, you need to do that or the BGP negotiation won't work...
>  i.e. config it to be 169.254.44.122/30 ..  Try restarting quagga and
> bgpd and it should pick up if the IPsec parts are good.
>
> if you run 'ip route show' on Linux natively you'll see the routes for
> your VPC and try checking your VPC network security rules/groups for basic
> IP/ICMP/UDP connectivity..
>
> try this link (found using a google of  "connecting linux openswan bgp aws
> vpc"
> http://blog.akquinet.de/2011/11/11/connecting-to-amazon-vpc/
>
> good luck
>
>
> On Feb 19, 2016, at 02:12 AM, Amos Shapira <amos.shapira at gmail.com> wrote:
>
> I forgot to include the output of *"ipsec auto --status"*, which should
> be useful:
>
> *000*
> *000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
> trans={0,0,0} attrs={0,0,0}*
> *000*
> *000 "amos-spoke-c-amos-hub-1":
> 10.20.50.0/24===10.20.50.15[52.4.101.228]...52.7.165.219
> <http://10.20.50.0/24===10.20.50.15%5B52.4.101.228%5D...52.7.165.219><52.7.165.219>===10.20.30.0/24
> <http://10.20.30.0/24>; erouted; eroute owner: #10*
> *000 "amos-spoke-c-amos-hub-1":     myip=unset; hisip=unset;*
> *000 "amos-spoke-c-amos-hub-1":   ike_life: 3600s; ipsec_life: 28800s;
> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0*
> *000 "amos-spoke-c-amos-hub-1":   policy:
> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24;
> interface: eth0;*
> *000 "amos-spoke-c-amos-hub-1":   newest ISAKMP SA: #12; newest IPsec SA:
> #10;*
> *000 "amos-spoke-c-amos-hub-1":   IKE algorithm newest:
> AES_CBC_128-SHA1-MODP2048*
> *000 "amos-spoke-c-amos-hub-2":
> 10.20.50.0/24===10.20.50.15[52.4.101.228]---169.254.44.209...54.173.211.136
> <http://10.20.50.0/24===10.20.50.15%5B52.4.101.228%5D---169.254.44.209...54.173.211.136><54.173.211.136>===10.20.30.0/24
> <http://10.20.30.0/24>; unrouted; eroute owner: #0*
> *000 "amos-spoke-c-amos-hub-2":     myip=169.254.44.210; hisip=unset;*
> *000 "amos-spoke-c-amos-hub-2":   ike_life: 3600s; ipsec_life: 28800s;
> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0*
> *000 "amos-spoke-c-amos-hub-2":   policy:
> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24;
> interface: eth0;*
> *000 "amos-spoke-c-amos-hub-2":   newest ISAKMP SA: #11; newest IPsec SA:
> #0;*
> *000 "amos-spoke-c-amos-hub-2":   IKE algorithm newest:
> AES_CBC_128-SHA1-MODP2048*
> *000*
> *000 #12: "amos-spoke-c-amos-hub-1":4500 STATE_MAIN_I4 (ISAKMP SA
> established); EVENT_SA_REPLACE in 2393s; newest ISAKMP; lastdpd=0s(seq in:0
> out:0); idle; import:admin initiate*
> *000 #10: "amos-spoke-c-amos-hub-1":4500 STATE_QUICK_R2 (IPsec SA
> established); EVENT_SA_REPLACE in 820s; newest IPSEC; eroute owner;
> isakmp#9; idle; import:admin initiate*
> *000 #10: "amos-spoke-c-amos-hub-1" esp.481523e2 at 52.7.165.219
> <esp.481523e2 at 52.7.165.219> esp.fdb3b3d8 at 10.20.50.15
> <esp.fdb3b3d8 at 10.20.50.15> tun.0 at 52.7.165.219 <tun.0 at 52.7.165.219>
> tun.0 at 10.20.50.15 <tun.0 at 10.20.50.15> ref=0 refhim=4294901761*
> *000 #9: "amos-spoke-c-amos-hub-1":4500 STATE_MAIN_I4 (ISAKMP SA
> established); EVENT_SA_EXPIRE in 454s; lastdpd=151s(seq in:0 out:0); idle;
> import:admin initiate*
> *000 #11: "amos-spoke-c-amos-hub-2":4500 STATE_MAIN_I4 (ISAKMP SA
> established); EVENT_SA_REPLACE in 2162s; newest ISAKMP; lastdpd=730s(seq
> in:0 out:0); idle; import:admin initiate*
> *000 #8: "amos-spoke-c-amos-hub-2":4500 STATE_MAIN_I4 (ISAKMP SA
> established); EVENT_SA_EXPIRE in 3s; lastdpd=3587s(seq in:0 out:0); idle;
> import:admin initiate*
>
> I notice that the first tunnel (the one which comes up) has *"myip=unset;
> hisip=unset;"* is this significant? The other tunnel probably has "myip"
> set because I set leftsourceip as part of my experiments.
>
> On 19 February 2016 at 12:58, Amos Shapira <amos.shapira at gmail.com> wrote:
>
>> Hello,
>>
>> I got OpenSwan talking to AWS Virtual Gateway just fine, and can now
>> route directly between two VPC's using static routes.
>> But I have to switch to BGP routing in order to do smarter routing (e.g.
>> have a Virtual Gateway act as a hub between multiple VPC's and non-VPC
>> networks).
>>
>> I tried configuring bgpd from Quagga but it fails to initiate the
>> connection, and I suspect that it might be related to the IPSec tunnel not
>> having routable end-points(?)
>> (I might be talking rubbish here, I'm a noob when it comes to ipsec).
>>
>> Here is the configuration I have in a test network. It's a VPC running
>> OpenSwan on Ubuntu 14.04 on EC2 with a subnet of 10.20.50/24 and connecting
>> to a Virtual GW in another VPC (the test "Hub") which has a subnet of
>> 10.20.30/24).
>>
>> *version 2.0*
>> *config setup*
>> * dumpdir=/var/run/pluto/*
>> * nat_traversal=yes*
>> *
>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10,%v4:!10.20.50.0/24*
>> * oe=off*
>> * protostack=netkey*
>> * interfaces=%defaultroute*
>> *include /etc/ipsec.d/*.conf*
>> *conn amos-spoke-c-amos-hub-1*
>> *    type=tunnel*
>> *    authby=secret*
>> *    forceencaps=yes*
>> *    auto=start*
>> *    left=%defaultroute*
>> *    leftid=52.4.101.228*
>> *    leftnexthop=%defaultroute*
>> *    leftsubnet=10.20.50.0/24 <http://10.20.50.0/24>*
>> *    right=52.7.165.219*
>> *    rightid=52.7.165.219*
>> *    rightsubnet=10.20.30.0/24 <http://10.20.30.0/24>*
>>
>>
>> bgpd.conf:
>>
>> *!*
>> *! Zebra configuration saved from vty*
>> *!   2016/02/18 05:51:54*
>> *!*
>> *hostname ip-10-20-50-15*
>> *password zebra*
>> *log stdout*
>> *!*
>> *debug bgp events*
>> *debug bgp keepalives*
>> *debug bgp updates*
>> *debug bgp fsm*
>> *debug bgp filters*
>> *!*
>> *router bgp 65102*
>> * bgp router-id 0.0.0.0*
>> * neighbor 169.254.44.121 remote-as 7224*
>> * neighbor 169.254.44.121 timers 10 30*
>> * neighbor 169.254.44.121 timers connect 30*
>> * neighbor 169.254.44.121 soft-reconfiguration inbound*
>> *!*
>> *line vty*
>> *!*
>>
>> The VirtualGateway configuration in generic format is below (I tried to
>> keep only relevant parts). I suspect that the issue boils down to that my
>> configuration doesn't mention any of the "*Inside IP Addresses*" from
>> that file, but I don't know how am I supposed to do that.
>>
>> Could you please explain to me what should I change?
>>
>> Thanks.
>>
>> *Amazon Web Services*
>> *Virtual Private Cloud*
>>
>> *IPSec Tunnel #1*
>>
>> *================================================================================*
>> *#1: Internet Key Exchange Configuration*
>>
>> *...*
>> *The Customer Gateway and Virtual Private Gateway each have two addresses
>> that relate*
>> *to this IPSec tunnel. Each contains an outside address, upon which
>> encrypted*
>> *traffic is exchanged. Each also contain an inside address associated
>> with*
>> *the tunnel interface.*
>>
>> *The Customer Gateway outside IP address was provided when the Customer
>> Gateway*
>> *was created. Changing the IP address requires the creation of a new*
>> *Customer Gateway.*
>>
>> *The Customer Gateway inside IP address should be configured on your
>> tunnel*
>> *interface. *
>>
>> *Outside IP Addresses:*
>> *  - Customer Gateway        : 52.4.101.228 *
>> *  - Virtual Private Gateway        : 52.7.165.219*
>>
>> *Inside IP Addresses*
>> *  - Customer Gateway         : 169.254.44.122/30
>> <http://169.254.44.122/30>*
>> *  - Virtual Private Gateway             : 169.254.44.121/30
>> <http://169.254.44.121/30>*
>>
>> *Configure your tunnel to fragment at the optimal size:*
>> *  - Tunnel interface MTU     : 1436 bytes*
>>
>> *#4: Border Gateway Protocol (BGP) Configuration:*
>>
>> *The Border Gateway Protocol (BGPv4) is used within the tunnel, between
>> the inside*
>> *IP addresses, to exchange routes from the VPC to your home network. Each*
>> *BGP router has an Autonomous System Number (ASN). Your ASN was provided *
>> *to AWS when the Customer Gateway was created.*
>>
>> *BGP Configuration Options:*
>> *  - Customer Gateway ASN          : 65102 *
>> *  - Virtual Private  Gateway ASN          : 7224*
>> *  - Neighbor IP Address      : 169.254.44.121*
>> *  - Neighbor Hold Time       : 30*
>>
>> *Configure BGP to announce routes to the Virtual Private Gateway. The
>> gateway*
>> *will announce prefixes to your customer gateway based upon the prefix
>> you *
>> *assigned to the VPC at creation time.*
>>
>> *...*
>> *(Tunnel 2 configuration removed)*
>>
>>
>>
>
>
> --
> <http://au.linkedin.com/in/gliderflyer>
> _______________________________________________
> 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
>
>


-- 
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160222/6e863fce/attachment-0001.html>


More information about the Users mailing list