Subject: Re: IPSec question - regarding esp/tunnel mode.
To: Bill Studenmund <firstname.lastname@example.org>
From: J. Buck Caldwell <email@example.com>
Date: 07/13/2003 13:55:24
That is EXACTLY what I was looking for. Thanks so much! See notes below...
Bill Studenmund wrote:
>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?
It actually has specific NAT entries for each of the /24s it has behind
it - those on the frame, that is. The corporate office has two /24s, one
for the data center (read: the stuff that all branches need access to
directly) and one for the 'corporate office' per se, then additional
/24s for each branch on the frame.
>>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.
I'm beginning to understand that.
>>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
So this means that any traffic coming from 126.96.36.199 to 188.8.131.52
(etc) will be encrypted, and it doesn't pay attention to the
already-translated address, right?
>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 184.108.40.206 220.127.116.11
>inet 192.168.1.1 192.168.0.1
>inet tunnel 18.104.22.168 22.214.171.124
>inet 192.168.1.1 192.168.2.1
>inet tunnel 126.96.36.199 188.8.131.52
>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, 184.108.40.206), 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.
Yea, I'm already using GIF tunnels for the routing - IPSec tunnels don't
seem very routeable.
Last question - by default, does this include pre-compression on the
IPSec packets, or do I need additional lines in the ipsec.conf to turn
Thanks again so much!