Subject: Re: IPSec question - regarding esp/tunnel mode.
To: J. Buck Caldwell <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/12/2003 19:03:01
On Fri, 11 Jul 2003, J. Buck Caldwell wrote:
> I'm setting up a large IPSec VPN WAN using NetBSD-1.6.1. After playing
> around quite a bit, I think I've got it working well, but I'm wondering
> about a few things.
> Consider this network: Corporate, with SDSL Internet providing a real
> IP4 address to interface ex0, NAT 192.168/16 behind ex1. Cisco router at
> 192.168.0.250 routing Frame Relay out to 20 different branches, each
> with their own 192.168.x/24.
Note: you really want ex1 to have a /24. If it keeps a /16, it overlaps
the whole VPN, and you'll get a routing mess. Or did you mean that NAT out
ex0 will do the whole /16, even though you only have a /24 in the office?
> To replace this, we are giving several of the branches (but not all) a
> broadband (mostly Cable) connection, and a NetBSD box to do NAT, DHCP,
> DNS, and VPN. Each branch will retain their existing 192.168.x/24
> private network. Each branch will have a IPSec tunnel to each other
> branch that has a broadband connection, all traffic for those left on
> frame will go to 192.168.0.1 (Corporate's gateway).
> First of all, I did a bad thing - I assumed that traffic would only be
> encrypted over the tunnel - and I ended up with encrypted traffic not
> being decrypted because it's destination address was outside of the
> 192.168.0/24. So, lots of additional spdadd's later, I've got it all
> working. Now I'm looking to make it effecient.
> Given Branch #1 (192.168.1/24) having a public IP of 188.8.131.52, and
> Corporate (192.168.0/24) having a public IP of 184.108.40.206), and Branch
> #2 (192.168.3/24) having public 220.127.116.11:
> Can I have a rule on the Corporate side that says:
> spdadd 192.168.0.0/16 192.168.1.0/24 any -P out ipsec
> spdadd 192.168.1.0/24 192.168.0.0/16 any -P in ipsec
> spdadd 192.168.0.0/16 192.168.2.0/24 any -P out ipsec
> spdadd 192.168.2.0/24 192.168.0.0/16 any -P in ipsec
I think you'll have a saner and happier time if you don't use tunnel mode.
> Note the different netmasks - I want to be able to send traffic
> encrypted from 192.168.1.1 (router) to 192.168.0.1, who decrypts it,
> then forwards it on to 192.168.0.250 to be routed to, say, 192.168.3.1,
> still on the Frame Relay.
> On the Branch #1:
> spdadd 192.168.1.0/24 192.168.0.0/16 any -P out ipsec
> spdadd 192.168.0.0/16 192.168.1.0/24 any -P in ipsec
> spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
> spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
> Note the first pair of rules have a /16 - In other words, I want any
> traffic that doesn't have a direct tunnel built to go to 18.104.22.168 for
> processing, but still have those that have better-fitting netmasks to go
> So, how far off am I? Please CC: replies, as I am off-list.
Ok. Let me see if I can remember what we did for this. This was a start-up
ago, but we were looking at a 100-node high-use VPN. We never got there,
but we figured out how to make it go.
You're looking at a complicated VPN, and life will be nicer if you have
IPsec one step and the Virtual Network another.
The big advantage is you can do routing on your VPN! As in routed. So say
branch #3 and #6 can't talk directly (for whatever reason), but branch #4
can talk to both. You can have traffic get routed via #4 automatically. Or
say branch #2 can't talk to the main office, but #5 can talk to both. You
can fail over to using #5 as an intermediary. The key advantage of this
VN/P separation is that any branch will now accept internal packets that
come via ANY of the branch routers, not just specifically the one it
Since a VPN is a private internet, what I'll describe is a way to let you
have all of the features of internet failover within this small internet.
Set up transport mode connections amongst all the branches, where you have
tunnel mode connections now. This way _any_ traffic between them is
As a concrete example (for the branch 1, I added branch #3 at 22.214.171.124):
spdadd 126.96.36.199-188.8.131.52 any -P out ipsec esp/transport//require
spdadd 184.108.40.206-220.127.116.11 any -P in ipsec esp/transport//require
spdadd 18.104.22.168-22.214.171.124 any -P out ipsec esp/transport//require
spdadd 126.96.36.199-188.8.131.52 any -P in ipsec esp/transport//require
spdadd 184.108.40.206-220.127.116.11 any -P out ipsec esp/transport//require
spdadd 18.104.22.168-22.214.171.124 any -P in ipsec eps/transport//require
Now, to do the VN part, use the gif interface. I'm assuming the routers
are at .1 on the local nets. Here's what'd be in the ifconfig files:
create #automatically create the interface
inet tunnel 126.96.36.199 188.8.131.52
inet 192.168.1.1 192.168.0.1
inet tunnel 184.108.40.206 220.127.116.11
inet 192.168.1.1 192.168.2.1
inet tunnel 18.104.22.168 22.214.171.124
inet 192.168.1.1 192.168.3.1
Your network, of course, would have more entries than that.
You now have interfaces: ex0 (local routed IP, 126.96.36.199), ex1 (local
192.168.1.0/24), gif0, gif1, and gif2. You want to run a routing daemon on
interfaces ex1, gif0, gif1, and gif2. I think we used routed, but I'm not
100% sure. You do NOT want the routing daemon to talk on interface ex0, as
that will either confuse it, and/or confuse your ISP.
If you don't want to run a routing daemon, you can just set up routes
manually for now. "route add -net 192.168.0.0 192.168.0.1 -netmask
255.255.0.0" "route add -net 192.168.2.0 192.168.2.1 -netmask 255.255.255.0"
and so on.