Tux

...making Linux just a little more fun!

Talkback:126/pfeiffer.html

[ In reference to "Digging More Secure Tunnels with IPsec" in LG#126 ]

René Pfeiffer [lynx at luchs.at]


Fri, 27 Apr 2007 21:30:59 +0200

Hello!

On Apr 26, 2007 at 1329 -0700, S. Banerian appeared and said:

> [...]
> I read through the two articles on use of setkey/racoon in
> linuxgazette/2006.
> The second article describes racoon configuration, but really only in
> terms of two private nets behind gateways.  My goal is to just connect a
> cluster of boxes together, on whatever subnets.

You can only use IPsec for creating an encrypted tunnel between two points in the network. If you wish to connect multiple hosts you need to create tunnels from one hosts to the others or use gateways that route through VPN tunnels.

> >From what I get out of the article, I might be able to just modify the
> sainfo block, using the two endpoints for each connection; however that
> does not "seem' to work; tcpdump tells me nothing appears encrypted.
> I've not found online any good peer-to-peer x509 description.

Can you tell me something more about your configuration? Maybe you can send an anonymised config file, so that I can see the relations between the IP addresses. I don't need to know your real IPs, just mark them in order to indicate private and public IP ranges.

> Do you have any recommendations for an A-B-C peer connection with x509 ?

One way would be to use static routes through multiple VPN tunnels. Another way would be to use a star topology and have one machine act as a VPN server where all the others connect to. This saves you some tunnels between indidivual hosts and requires the VPN server in the middle to reroute all the traffic. Yet another way is to try a mesh. tinc (https://www.tinc-vpn.org/) is used by the German Chaos Computer Club to link multiple sites with a kind of mesh topology. It doesn't seem to support X.509 though.

Best wishes, René.


Top    Back


René Pfeiffer [lynx at luchs.at]


Sat, 28 Apr 2007 01:59:47 +0200

On Apr 27, 2007 at 1427 -0700, S. Banerian appeared and said:

> René Pfeiffer wrote:
> > [...]
> > One way would be to use static routes through multiple VPN tunnels.
> > Another way would be to use a star topology and have one machine act as
> > a VPN server where all the others connect to. This saves you some
> > tunnels between indidivual hosts and requires the VPN server in the
> > middle to reroute all the traffic. Yet another way is to try a mesh.
> > tinc (https://www.tinc-vpn.org/) is used by the German Chaos Computer
> > Club to link multiple sites with a kind of mesh topology. It doesn't
> > seem to support X.509 though. [...]
>=20
> I am trying to get ahead of the system here at work, which is highly
> MS-centric, and get our Linux boxes connected via IPSEC tunnels [...]
>=20
> So, IPSEC is pretty much what I need to do, and x509 certs are part of
> the plan...
>=20
> I've been able to get boxes to work with setkey, as in your first
> article, but if the hospital wants to have x509, then it seemed as
> though racoon would be appropriate.

I see. I use a setup with X.509 on a daily basis in order to link with my office network. I'll give you the configuration as example. I have a fixed IP address at home (let's say on machine $HOME). Our office firewall (which is denoted $FIREWALL) runs GNU/Linux with the network 10.23.23.0/24 in the LAN. Then you should be able to build a tunnel by having the following two entries in your racoon.conf.

$HOME:
 
path certificate "/etc/racoon/certs";
log notify;
listen {
	isakmp $HOME [500];
	isakmp_natt $HOME [4500];
	strict_address;
}
listen {
	strict_address;
}
listen {
	strict_address;
}
 
remote $FIREWALL {
	exchange_mode main;
	generate_policy off;
	passive off;
	certificate_type x509 "workstation.luchs.at.cert" "workstation.luchs.at.ke=
y";
	ca_type x509 "ca-cert.pem";
	my_identifier asn1dn;
	peers_identifier asn1dn;
	verify_identifier on;
	proposal {
		encryption_algorithm aes;
		hash_algorithm sha1;
		authentication_method rsasig;
		dh_group modp1024;
	}
}
 
sainfo anonymous {
	pfs_group modp1024;
	lifetime time 240 min;
	encryption_algorithm aes;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}
 
$FIREWALL:
 
# The firewall acts as VPN server, so we use anonymous as configuration.
remote anonymous {
        exchange_mode main;
        generate_policy on;
        passive on;
        certificate_type x509 "firewall.luchs.at.cert" "firewall.luchs.at.key";
        ca_type x509 "ca-cert.pem";
        my_identifier asn1dn;
        peers_identifier asn1dn;
        verify_identifier on;
        proposal {
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group modp1024;
        }
}
 
sainfo anonymous {
        pfs_group modp1024;
        lifetime time 240 min;
        encryption_algorithm aes;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}
The *.cert and *.key files are your X.509 certificate and key. ca-cert.pem should be the certificate of your CA. Then the only thing you will need is the security policy between the two hosts. In my case I have

spdadd $HOME 10.23.23.0/24 any -P out ipsec esp/tunnel/$HOME-$FIREWALL/require;
spdadd 10.23.23.0/24 $HOME any -P in  ipsec esp/tunnel/$FIREWALL-$HOME/require;
and vice versa on the firewall. I think it is the same for linking hosts, but you just have the hosts' IP addresses in the security policy. Provided I didn't forget anything this should work. Let us or me know if you need anything else.

Best wishes, René.


Top    Back