[Openswan Users] build openswan 2.6.26 rpm with klips kernel module
Steve Zeng
SteveZ at airg.com
Fri May 28 18:40:16 EDT 2010
> 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:
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.
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.
thanks,
--steve
-----Original Message-----
From: Michael H. Warfield [mailto:mhw at wittsend.com]
Sent: May 28, 2010 1:23 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 10:50 -0700, Steve Zeng wrote:
> > I'm not sure if you provided fake addresses up there but, obviously "169.254.*" addresses are not going to work as interface addresses.
> >I can't tell how the Amazon VPN gateway is set up. I'm not familiar with that at all. Is it configured to tunnel your private /24 back through it? How would any of the other addresses in that 10.* net know to route to you? Is that something you can control or you can specify?
> >I guess I'm really asking how that whole service runs its VPN service.
>
> I am not quite clear either. No control is given by amazon how it
> works on their end. The only document available is as follows:
>
> ======================================================================
> ========== Your Customer Gateway must be configured with a tunnel
> interface that is associated with the IPSec tunnel. All traffic
> transmitted to the tunnel interface is encrypted and transmitted to
> the VPN Gateway.
> Additionally, the VPN Gateway and Customer Gateway establish the BGP
> peering from your tunnel interface.
Oh really? They're asking you to bring up a BGP peering session as well? That explains the network routing question and how routing the various networks on either side should get handled but that changes issues with IPSec since anything BGP negotiates has to also be configured in OpenSWAN. I hope they've given you some guidance on that.
If you need to be doing that, you'll probably be using the Quagga suite (I did quite a bit of the md5sum logic in the BGP daemon of quagga) on Fedora or RedHat. It's not generally a trivial exercise diving into BGP.
> The Customer Gateway and VPN 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: : x.x.x.x (public IP of my end)
> - VPN Gateway : y.y.y.y (public IP of amazon end)
>
> Inside IP Addresses
> - Customer Gateway : 169.254.255.2/30
> - VPN Gateway : 169.254.255.1/30
> ======================================================================
> ==========
Ok... NOW I understand. They're using the rfc3927 link local address for the private interface addresses. I'm not totally sure how proper that is and there's always a risk of conflict with them but, oh well.
> At the moment, I could not figure out how to make the tunnel interface
> with netkey. That is what I am hoping klips can provide so that I can
> attach 169.254.255.2 to it. currently I manually create a linux/tunnel
> interface but then I got the routing problem. any idea?
> # ifconfig tunl0
> tunl0 Link encap:IPIP Tunnel HWaddr
> inet addr:169.254.255.2 Mask:255.255.255.252
I'll probably get some of the details cross-wise here, since I really haven't done your exact setup (but it sounds like it would be fun to try
- for some value of "fun"...). Maybe someone else has set this up and I would love to see a working setup for it. this should be the basics and it certainly sounds like it should work fine with netkey.
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.
Then, in your connections, you need to specify your "Outside Address" in "left=", his "Outside Address" in "right=". Then specify "leftsubnet=169.254.255.2" (don't specify the /30 here) and "rightsubnet=169.254.255.1/30" in that connection.
As far as network routing goes, as bgpd and quagga bring up routes to anything over on their side, you have to bring those matching tunnels with leftsubnet and rightsubnet specifications up and add the routes in using "ip route add ... src 169.254.255.2" which is handled in /usr/libexec/ipsec/_updown.netkey. I'm not totally sure you can bring those connections up before bgpd negotiates the routes and quagga adds them. I haven't tried getting OpenSwan and Quagga to play nice with each other for dynamic tunnels.
For networks on your side, you'll have to add those networks as advertisments in bgpd, I presume. I'm not sure what they are allowing you to do over BGP and what they're not. They should be VERY restrictive of what networks you can advertise and you'll probably be using a private ASN for that, in any case.
That's all leaving out the missing details of "how is this keyed and set up". I would hope they would have provided you more information there.
There may be another way of doing it but I don't think KLIPS is going to be much different or much simpler, especially if you have to get BGP cranked up and involved in all this. Once BGP and dynamic routing are involved, it becomes a horse of a different color.
> any
> Steve
Regards,
Mike
>
> -----Original Message-----
> From: Michael H. Warfield [mailto:mhw at WittsEnd.com]
> Sent: May 28, 2010 6:28 AM
> 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 Thu, 2010-05-27 at 22:37 -0700, Steve Zeng wrote:
> > Thanks, Michael. I am looking for a .spec file to build openswan rpm with klips included. The reason for klips is, I have a problem related to routing (I think) when trying openswan with amazon VPC. What I've been given regarding the IPSec tunnel is:
>
> > My_network (192.168.1.0/24)
> > ||
> > my IPSec VPN gateway (tunnel interface: 169.254.255.2)
> > ||
> > Internet
> > ||
> > Amazon VPN gateway (tunnel interface: 169.254.255.1)
> > ||
> > vpc (10.0.0.0/24)
>
> > with netkey I have difficulty to implement the routing. My understanding is, klips will give me a tunnel interface and so I can ajust my routing table to let all traffic to 10.0.0.0/24 go through the tunnel interface. Correct me if I am wrong.
>
> 1) I do this sort of thing all the time with netkey with no problem (although my environment is public addresses and I don't have to resort to private addresses at either end). I have run into some problems with the local net talking to the local gateway that require one or more bypass routes to be installed with netkey which are not required for klips, as I understand, and I even had to write some patches to make that work (which were incorporated into openswan 2.6 some time ago).
>
> 2) You don't have to "implement" the routing. It's handled by the VPN policies and transforms. IOW, get the connections right and your done.
> If by "getting the routing right" you mean you're doing something with "ip route" or "route", then you're doing something wrong.
>
> 3) Even with klips, IPSec is still fundamentally, by spec, a policy VPN.
> Merely setting routes through the interfaces without having set the tunnel policies properly with still probably fail for you.
>
> I'm not sure if you provided fake addresses up there but, obviously "169.254.*" addresses are not going to work as interface addresses.
>
> I can't tell how the Amazon VPN gateway is set up. I'm not familiar with that at all. Is it configured to tunnel your private /24 back through it? How would any of the other addresses in that 10.* net know to route to you? Is that something you can control or you can specify?
> I guess I'm really asking how that whole service runs its VPN service.
> I often have to include IPv4 NAT on one or more of the gateways because of reverse routing and the absence of control of the routing to the other machines when I'm NOT in the default route.
>
> If you're really dead set on using klips and rpm's, it looks like some people have created kernel rpm's with klips (which makes a hell of a lot more sense than trying to build Openswan with a kernel module) but it was some time ago. Here's a SmoothWall refererence to a procedure that might work for you:
>
> https://support.smoothwall.net/index.php?_m=knowledgebase&_a=viewartic
> le&kbarticleid=250
>
>
> > Steve
>
> Regards,
> Mike
>
> >
> > -----Original Message-----
> > From: Michael H. Warfield [mailto:mhw at WittsEnd.com]
> > Sent: May 27, 2010 6:43 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 Thu, 2010-05-27 at 17:05 -0700, Steve Zeng wrote:
> > > Anybody has a spec file available to build openswan-2.6.26 rpm with klips kernel module on redhat/Centos/Fedora?
> >
> > When you said "spec" file, I presumed you mean the .spec file for building rpm's, especially since you then mentioned Fedora and Redhat.
> > I realized later, you didn't really refer to building rpms per se. Are you building rpm's or what "spec" file do you mean?
> >
> > > I tried to run "make KERNELSRC=/lib/modules/`uname -r`/build module minstall" but get the following errors:
> > >
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c: In function âipsec_tunnel_hard_headerâ:
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: implicit declaration of function âip_hdrâ
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1072:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1098:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c: In function âipsec_tunnel_rebuild_headerâ:
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1174:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1193:
> > > error: invalid type argument of â->â
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c: In function âipsec_tunnel_cache_updateâ:
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1327:
> > > warning: passing argument 1 of ânetdev_privâ discards qualifiers
> > > from pointer target type
> > > /usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.c:1376:
> > > warning: passing argument 3 of âprv->header_cache_updateâ discards
> > > qualifiers from pointer target type
> > > make[3]: ***
> > > [/usr/src/redhat/BUILD/openswan-2.6.26/modobj26/ipsec_tunnel.o]
> > > Error
> > > 1
> > > make[2]: ***
> > > [_module_/usr/src/redhat/BUILD/openswan-2.6.26/modobj26]
> > > Error 2
> > > make[2]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
> > > make[1]: *** [module26] Error 2
> > > make[1]: Leaving directory `/usr/src/redhat/BUILD/openswan-2.6.26'
> > > make: *** [module] Error 2
> > >
> > > Thanks in advance.
> > >
> > > Steve
> >
> > 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!
> >
>
> --
> 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!
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=2831
> 55
>
--
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