[Openswan Users] build openswan 2.6.26 rpm with klips kernel module
Michael H. Warfield
mhw at wittsend.com
Fri May 28 16:23:25 EDT 2010
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=viewarticle&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=283155
>
--
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20100528/80f328c4/attachment-0001.bin
More information about the Users
mailing list