Thread: [Ipsec-tools-users] Chaining IPSec VPNs
Brought to you by:
mit_warlord,
netbsd
From: <ne...@sk...> - 2007-02-11 16:29:33
|
Hello, I am working on a performance evaluation of different VPN technologies =20 and I am stumped because I would like to set up chained IPSec VPNs =20 like this: server (10.0.0.2/24) | | (10.0.0.1/24) box1 (192.168.255.1/30) || || IPsec || (192.168.255.2/30) box2 (192.168.255.5/30) || || IPSec || (192.168.255.6/30) box3 (10.0.1.1/24) | | (10.0.1.2/24) client I would like to make 2 VPN connections here: from box1 to box2 and =20 from box2 to box3. I know that that doesn't really present a practical =20 situation, but I am also testing IPSec scalability when the number of =20 passed VPN connections increases. I am using FreeBSD 6.1 on all of these machines with ipsec-tools =20 0.6.6. I can use OpenBSD's pf if I need NAT or something. So far, I =20 have successfully established a VPN between box1 and box2 with these =20 "secure groups": box1: spdadd 10.0.0.0/24 10.0.1.0/24 any -P out ipsec =20 esp/tunnel/192.168.255.1-192.168.255.2/unique; spdadd 10.0.1.0/24 10.0.0.0/24 any -P in ipsec =20 esp/tunnel/192.168.255.2-192.168.255.1/unique; box2: spdadd 10.0.1.0/24 10.0.0.0/24 any -P out ipsec =20 esp/tunnel/192.168.255.2-192.168.255.1/unique; spdadd 10.0.0.0/24 10.0.1.0/24 any -P in ipsec =20 esp/tunnel/192.168.255.1-192.168.255.2/unique; And with only one VPN, everything works great, the packets from =20 10.0.0.0/24 and 10.0.1.0/24 networks traverse seamlessly. But now I =20 would like to add another VPN between box2 and box3. The problem is =20 that this would require almost the same 'spdadd' clauses - only the =20 secure gateways need to be changed (192.168.255.5 and 192.168.255.6 =20 instead of 192.168.255.1 and 192.168.255.2). However, if I try to do this, I get: root@Blackbox2:~# /etc/rc.d/ipsec restart Clearing ipsec manual keys/policies. Installing ipsec manual keys/policies. The result of line 11: File exists. The result of line 12: File exists. which I understand since the "secure groups" (networks in the VPN) are =20 the same. I tried to play with NAT but the problem is that the IPSec =20 encapsulation decisions are made prior to pf/NAT evaluation (when =20 packet is going OUT of the interface, after leaving the routing =20 process) which causes this idea to fail on FreeBSD/OpenBSD machines =20 (it is not (yet) possible to change the order of these processes). Any ideas what I could try in order to measure IPSec chaining =20 scalability? I have already got the results when using OpenVPN =20 protocol - it is simple to chain VPNs there - and I find the results =20 quite interesting. I hope you guys will able to help me out. Thanks, Nejc ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <ne...@sk...> - 2007-02-12 15:55:11
|
> And with only one VPN, everything works great, the packets from > 10.0.0.0/24 and 10.0.1.0/24 networks traverse seamlessly. But now I > would like to add another VPN between box2 and box3. The problem is > that this would require almost the same 'spdadd' clauses - only the > secure gateways need to be changed (192.168.255.5 and 192.168.255.6 > instead of 192.168.255.1 and 192.168.255.2). I solved this by using a trick - changing the subnet mask of the networks helped - so the first VPN is with masks /24, the second is then with /25 and then again with /24 ... it works, although it is quite funny. Bye, Nejc |
From: VANHULLEBUS Y. <va...@fr...> - 2007-02-12 16:05:16
|
On Sun, Feb 11, 2007 at 05:29:24PM +0100, ne...@sk... wrote: > Hello, Hi. > I am working on a performance evaluation of different VPN technologies > and I am stumped because I would like to set up chained IPSec VPNs > like this: > [....] > And with only one VPN, everything works great, the packets from > 10.0.0.0/24 and 10.0.1.0/24 networks traverse seamlessly. But now I > would like to add another VPN between box2 and box3. The problem is > that this would require almost the same 'spdadd' clauses - only the > secure gateways need to be changed (192.168.255.5 and 192.168.255.6 > instead of 192.168.255.1 and 192.168.255.2). No, it wouldn't be the same SPD entries: directions (in and out) will be reverted. You'll have: spdadd Net1 Net2 any -P in esp/tunnel/GateA-GateB/require; # for the first tunnel spdadd Net1 Net2 any -P out esp/tunnel/GateB-GateC/require; # for the second tunnel and of course, you'll also have to do the rules for traffic from Net2 to Net1. And this kind of setup *does* work. Yvan. |