<br><br><div class="gmail_quote">2011/5/4 Neal Murphy <span dir="ltr"><<a href="mailto:neal.p.murphy@alum.wpi.edu">neal.p.murphy@alum.wpi.edu</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wednesday 04 May 2011 11:31:43 Luc Paulin wrote:<br>
> internal's ip (169.254.255.x), however when I try to ping the other side's<br>
> network, the I amd getting destination host unreachable. The routing<br>
> table does properly show and entry to route the network through the<br>
> correct gateway (amazon's internal ip).<br>
><br>
> Not sure If I did the right thing but I assign the internal ip adresses<br>
> 169.254.255.2 and 169.254.255.6 to the interface eth0 of our vpn server,<br>
> which is the public facing interface. I actually did an almost same copy<br>
> as per this email thread setup<br>
> (<a href="http://lists.openswan.org/pipermail/users/2010-May/018829.html" target="_blank">http://lists.openswan.org/pipermail/users/2010-May/018829.html</a>).<br>
><br>
><br>
><br>
> After doing more testing, I found the proper configuration to make<br>
> end-to-end ping connectivity. However, over 50% of the packet are getting<br>
> lost, configuration is as follow...<br>
><br>
> conn amazonvpc1<br>
> type= tunnel<br>
> authby=secret<br>
> left=207.96.182.176<br>
> leftsubnets={<a href="http://169.254.255.2/32,192.168.0.0/16" target="_blank">169.254.255.2/32,192.168.0.0/16</a>}<br>
> right=72.21.209.225<br>
> rightsubnets={<a href="http://169.254.255.1/32,10.0.0.0/8" target="_blank">169.254.255.1/32,10.0.0.0/8</a>}<br>
<br>
</div>Shouldn't most routers refuse to route link-local addresses (those in<br>
<a href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a>) because they have no meaning outside the immediate<br>
link/context? If you assign link-local addresses to the VPN endpoints, you<br>
shouldn't be able to reference those addresses from anywhere else, mainly<br>
because the addresses you chose can be duplicated anywhere and everywhere<br>
else.<br></blockquote><div><br><br>Well I have no control on amazon's side. The only information provided from them is the following...<br>
<br>
================================================================================<br>
#1: Internet Key Exchange Configuration<br>
<br>
Configure the IKE SA as follows<br>
- Authentication Method : Pre-Shared Key <br>
- Pre-Shared Key : <PRE-SHARED_KEY><br>
- Authentication Algorithm : sha1<br>
- Encryption Algorithm : aes-128-cbc<br>
- Lifetime : 28800 seconds<br>
- Phase 1 Negotiation Mode : main<br>
- Perfect Forward Secrecy : Diffie-Hellman Group 2<br>
<br>
#2: IPSec Configuration<br>
<br>
Configure the IPSec SA as follows:<br>
- Protocol : esp<br>
- Authentication Algorithm : hmac-sha1-96<br>
- Encryption Algorithm : aes-128-cbc<br>
- Lifetime : 3600 seconds<br>
- Mode : tunnel<br>
- Perfect Forward Secrecy : Diffie-Hellman Group 2<br>
<br>
IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We<br>
recommend configuring DPD on your endpoint as follows:<br>
- DPD Interval : 10<br>
- DPD Retries : 3<br>
<br>
IPSec ESP (Encapsulating Security Payload) inserts additional<br>
headers to transmit packets. These headers require additional space, <br>
which reduces the amount of space available to transmit application data.<br>
To limit the impact of this behavior, we recommend the following <br>
configuration on your Customer Gateway:<br>
- TCP MSS Adjustment : 1396 bytes<br>
- Clear Don't Fragment Bit : enabled<br>
- Fragmentation : Before encryption<br>
<br>
#3: Tunnel Interface Configuration<br>
<br>
Your Customer Gateway must be configured with a tunnel interface that is<br>
associated with the IPSec tunnel. All traffic transmitted to the tunnel<br>
interface is encrypted and transmitted to the VPN Gateway.<br>
<br>
Additionally, the VPN Gateway and Customer Gateway establish the BGP<br>
peering from your tunnel interface. <br>
<br>
The Customer Gateway and VPN Gateway each have two addresses that relate<br>
to this IPSec tunnel. Each contains an outside address, upon which encrypted<br>
traffic is exchanged. Each also contain an inside address associated with<br>
the tunnel interface.<br>
<br>
The Customer Gateway outside IP address was provided when the Customer Gateway<br>
was created. Changing the IP address requires the creation of a new<br>
Customer Gateway.<br>
<br>
The Customer Gateway inside IP address should be configured on your tunnel<br>
interface. <br>
<br>
Outside IP Addresses:<br>
- Customer Gateway: : <MY_PUBLIC_IP><br>
- VPN Gateway : 72.21.209.225<br>
<br>
Inside IP Addresses<br>
- Customer Gateway : <a href="http://169.254.255.2/30">169.254.255.2/30</a><br>
- VPN Gateway : <a href="http://169.254.255.1/30">169.254.255.1/30</a><br>
<br>
Configure your tunnel to fragment at the optimal size:<br>
- Tunnel interface MTU : 1436 bytes<br>
<br>
#4: Border Gateway Protocol (BGP) Configuration:<br>
<br>
The Border Gateway Protocol (BGPv4) is used within the tunnel, between the inside<br>
IP addresses, to exchange routes from the VPC to your home network. Each<br>
BGP router has an Autonomous System Number (ASN). Your ASN was provided <br>
to AWS when the Customer Gateway was created.<br>
<br>
BGP Configuration Options:<br>
- Customer Gateway ASN : 65000 <br>
- VPN Gateway ASN : 7224<br>
- Neighbor IP Address : 169.254.255.1<br>
- Neighbor Hold Time : 30<br>
<br>
Configure BGP to announce the default route (<a href="http://0.0.0.0/0">0.0.0.0/0</a>) to the VPN Connection<br>
Gateway. The VPN Gateway will announce prefixes to your Customer <br>
Gateway based upon the prefixes assigned in the creation of the VPC.<br>
================================================================================<br>
<br><br><br> </div></div>-- <br> !!!!!<br> ( o o )<br> --------------oOO----(_)----OOo--------------<br> Luc Paulin | paulinster(at)<a href="http://gmail.com" target="_blank">gmail.com</a><br>
<br><br>