[Openswan Users] build openswan 2.6.26 rpm with klips kernel module
Steve Zeng
SteveZ at airg.com
Tue Jun 1 15:17:39 EDT 2010
I re-installed the rpm version of openswan from:
http://www.openswan.org/download/binaries/centos/5/without-nss/openswan-2.6.24rc5-1.i386.rpm
and it seems the packet loss problem between tunnel interfaces is resolved. That is good sign. However, I could not ping from my private network to amazon vpc instances any more. From what I can see, it seems related to iptables firewall rules. Tcpdump shows me there is ICMP echo back from amazon vpc but from my workstation I can not get anything.
On my firewall/VPN gateway:
=============================
[root at fw1 ~]# tcpdump -nlpi eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:47:42.372442 IP 10.0.0.4 > 192.168.1.39: ICMP echo reply, id 512, seq 29823, length 40
18:47:47.871616 IP 10.0.0.4 > 192.168.1.39: ICMP echo reply, id 512, seq 30079, length 40
18:47:53.412554 IP 10.0.0.4 > 192.168.1.39: ICMP echo reply, id 512, seq 30335, length 40
18:48:09.871474 IP 10.0.0.4 > 192.168.1.39: ICMP echo reply, id 512, seq 31103, length 40
On my workstation:
====================
C:\Documents and Settings\stevez>ping 10.0.0.4 -t
Pinging 10.0.0.4 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
I did not find anything wrong on my firewall configs, though.
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 500 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Amazon IPSec gateways
-A RH-Firewall-1-INPUT -s y.y.y.y/32 -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -j MARK --set-mark 0x9
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-I POSTROUTING -s 192.168.1.0/24 -d ! 10.0.0.0/24 -o eth1 -j MASQUERADE
-A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
COMMIT
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!
More information about the Users
mailing list