[Openswan Users] Connecting to AWS with BGP routing
Amos Shapira
amos.shapira at gmail.com
Mon Feb 22 20:41:23 EST 2016
The iptables on the EC2 instance are completely open, here is the output of
"iptables-save":
*# iptables-save*
*# Generated by iptables-save v1.4.21 on Tue Feb 23 01:23:20 2016*
**mangle*
*:PREROUTING ACCEPT [17583:3158164]*
*:INPUT ACCEPT [17583:3158164]*
*:FORWARD ACCEPT [0:0]*
*:OUTPUT ACCEPT [11016:2593217]*
*:POSTROUTING ACCEPT [11011:2592797]*
*COMMIT*
*# Completed on Tue Feb 23 01:23:20 2016*
*# Generated by iptables-save v1.4.21 on Tue Feb 23 01:23:20 2016*
**nat*
*:PREROUTING ACCEPT [1039:77947]*
*:INPUT ACCEPT [1002:75727]*
*:OUTPUT ACCEPT [2129:1101726]*
*:POSTROUTING ACCEPT [1730:1056280]*
*-A POSTROUTING -s 10.20.50.0/24 <http://10.20.50.0/24> ! -d 172.16.0.0/12
<http://172.16.0.0/12> -o eth0 -j MASQUERADE*
*COMMIT*
*# Completed on Tue Feb 23 01:23:20 2016*
*# Generated by iptables-save v1.4.21 on Tue Feb 23 01:23:20 2016*
**filter*
*:INPUT ACCEPT [31063:13469765]*
*:FORWARD ACCEPT [0:0]*
*:OUTPUT ACCEPT [19564:3614778]*
*COMMIT*
*# Completed on Tue Feb 23 01:23:20 2016*
That POSTROUTING rule is meant to let this EC2 instance be used as a
standard NAT gateway for any other EC2 instance on the same VPC.
The Security Group for this instance allows all incoming traffic (not just
TCP, UDP or ICMP - but everything) from anywhere and lets outgoing TCP port
179 to everywhere.
The peer on the other side of the tunnel is an Amazon Virtual Gateway.
There is no Security Group involved in its access control.
I now noticed that I can't access TCP port 179 on that Virtual GW from
anywhere (I tried using telnet over the tunnel, public IP address, my
laptop at the office, even from an EC2 instance on the VPC to which the
Virtual GW is attached). I sent a question to AWS Developer Support about
this.
Thanks.
On 23 February 2016 at 12:05, Daniel Cave <dan.cave at me.com> wrote:
> Are you sure you have got the correct firewall rules at your side to allow
> bgp ? You might have to move the AWS peer up to the outbound facing address
> if you can't get it working on loopback. I'm not sure as I've only assigned
> it to a tunnel interface and I don't have the config examples as they're
> with my old client
>
> Sent from my iPhone
>
> On 22 Feb 2016, at 23:40, Amos Shapira <amos.shapira at gmail.com> wrote:
>
> Thanks Daniel.
>
> I did that using the following commands:
>
> * # ip addr add 169.254.44.210 peer 192.254.44.209/30
> <http://192.254.44.209/30> scope link dev lo*
> * # ip addr add 169.254.44.122 peer 192.254.44.121/30
> <http://192.254.44.121/30> scope link dev lo*
>
> And now the interface configuration looks like this:
>
> # ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
> default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet 169.254.44.210 peer 192.254.44.209/30 scope link lo
> valid_lft forever preferred_lft forever
> inet 169.254.44.122 peer 192.254.44.121/30 scope link lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether 12:c2:ff:69:59:55 brd ff:ff:ff:ff:ff:ff
> inet 10.20.50.9/24 brd 10.20.50.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::10c2:ffff:fe69:5955/64 scope link
> valid_lft forever preferred_lft forever
>
> I can ping the other side's address but the times and TTL suggest that the
> ping is actually going to my own server.
>
> I still can't connect to port 179 on the other IP.
>
> I restarted quagga services (bgpd and zebra) and see that bgpd is still
> stuck on "SYN_SENT" to 169.254.44.121:179 and 169.254.44.209 (the "Inside
> Address" of the remote, AWS Virtual GW, side of the IPSec tunnel).
>
> Here is the output of "ipsec watch"
>
> *# ipsec look*
> *ip-10-20-50-9 Mon Feb 22 23:37:37 UTC 2016*
> *XFRM state:*
> XFRM policy:
> src 10.20.50.0/24 dst 10.20.30.0/24
> dir out priority 2344
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 0 mode transport
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> XFRM done
> IPSEC mangle TABLES
> iptables: No chain/target/match by that name.
> ip6tables: No chain/target/match by that name.
> NEW_IPSEC_CONN mangle TABLES
> iptables: No chain/target/match by that name.
> ip6tables: No chain/target/match by that name.
> ROUTING TABLES
> default via 10.20.50.1 dev eth0
> 10.20.50.0/24 dev eth0 proto kernel scope link src 10.20.50.9
> fe80::/64 dev eth0 proto kernel metric 256
>
>
> On 23 February 2016 at 08:43, Daniel Cave <dan.cave at me.com> wrote:
>
>> Amos. You need to configure loopback with the 169.254.44.122 Client side
>> otherwise the networking parts won't work.
>>
>> Sent from my iPhone
>>
>> On 22 Feb 2016, at 00:02, Amos Shapira <amos.shapira at gmail.com> wrote:
>>
>> 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>
>>
>>
>
>
> --
> <http://au.linkedin.com/in/gliderflyer>
>
>
--
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160223/b1c097d0/attachment-0001.html>
More information about the Users
mailing list