[Openswan Users] build openswan 2.6.26 rpm with klips kernel module

[Steve Zeng]

> Now that just doesn't make sense to me.  That's literally point-to-point between the two gateways with the addition of the encryption.  There should be no difference between that and pinging between the two external gateway addresses.

Agree. I am trying to get amazon guy to help troubleshoot. 

Thanks Mike. I will keep the list posted. 

Steve

-----Original Message-----
From: Michael H. Warfield [mailto:mhw at WittsEnd.com] 
Sent: May 28, 2010 4:31 PM
To: Steve Zeng
Cc: mhw at WittsEnd.com; Users at openswan.org
Subject: RE: [Openswan Users] build openswan 2.6.26 rpm with klips kernel module

On Fri, 2010-05-28 at 15:40 -0700, Steve Zeng wrote: 
> > Oh really?  They're asking you to bring up a BGP peering session as well?
> >>You don't need to use an explicit tunnel interface with netkey.  What you generally do is, when the tunnel is brought up, add your "internal address" as an additional address to the real interface.  When you're communicating with the OTHER "inside" address, the kernel automatically chooses that as your local address and then the ordered pair of your address and his address trips the policy database and it gets dumped through IPSec and netkey before shipping over.  I've got some of that going now with interfacing to some Cisco units but we're using full public addresses, not the link local autoconf addresses.  You don't have to set up any tunnels, though you may need to manually add your internal address and subnet to your real interface.

> That is a good explanation to me on how netkey handle the tunnel. I 
> also moved tunnel ip(169.254.255.2/30) to my public interface as well.
> Yeah. I've get BGP working and the BGP advertisement from Amazon is 
> shown up on my side:

> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 169.254.255.0   0.0.0.0         255.255.255.252 U     0      0        0 eth1
> 10.0.0.0        169.254.255.1   255.255.255.0   UG    100    0        0 eth1
> 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 0.0.0.0         r.r.r.r         0.0.0.0         UG    0      0        0 eth1

> As paul helped me out on my ipsec.conf, currently my ipse.conf is as follows:

Paul is da man.  Absolutely.

> config setup
>         interfaces=%defaultroute
>         protostack=netkey
>         klipsdebug=none
>         plutodebug=none
> 
> conn ec2-tunnel-01
>         type=           tunnel
>         authby=         secret
>         auth=           esp
>         keyexchange=    ike
>         ike=            aes128-sha1-modp1024
>         ikelifetime=    28800s
>         pfs=            yes
>         esp=            aes128-sha1
>         salifetime=     3600s
>         dpdtimeout=     10
>         dpddelay=       3
>         left=           x.x.x.x
>         right=          y.y.y.y
>         leftsubnets=    {169.254.255.2/30,192.168.1.0/24}
>         rightsubnets=   {169.254.255.1/30,10.0.0.0/24}
>         auto=           start
> 
> the problem for this config is, ping between 169.254.255.2 and
> 169.254.255.1 got about 50% loss. The good thing is, I will be able to 
> ping from my network (192.168.1.0/24) to amazon vpc (10.0.0.0/24) with 
> 50% packet loss as well.

Now that just doesn't make sense to me.  That's literally point-to-point between the two gateways with the addition of the encryption.  There should be no difference between that and pinging between the two external gateway addresses.

> If I replace leftsubnets= and rightsubnets= with the following configs:
> 
> #        leftsubnets=    {169.254.255.2/30,192.168.1.0/24}
> #        rightsubnets=   {169.254.255.1/30,10.0.0.0/24}
>        leftsubnet=    169.254.255.2/30
>        rightsubnet=   169.254.255.1/30
> 
> the ping test between 169.254.255.2 and 169.254.255.1 is 100% success.
> BGP still works. but I lose the ability to ping from my network
> (192.168.1.0/24) to amazon vpc (10.0.0.0/24). It is a puzzle to me.

That BGP works is good.  That's over 179/tcp with full stream and recoverability.  Loss of the other is a puzzle.  If all the policies are in place for those routes, it should not be happening.

> thanks,

> --steve

-- Trim -- Trim -- Trim

Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!