[Openswan Users] Connecting to AWS with BGP routing
Amos Shapira
amos.shapira at gmail.com
Mon Feb 22 18:40:52 EST 2016
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160223/2619cc78/attachment-0001.html>
More information about the Users
mailing list