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 30.30.30.1, and
>>Corporate (192.168.0/24) having a public IP of 20.20.20.1), and Branch
>>#2 (192.168.3/24) having public 40.40.40.1:
>>
>>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
>>esp/tunnel/20.20.20.1-30.30.30.1/require;
>>spdadd 192.168.1.0/24 192.168.0.0/16 any -P in ipsec
>>esp/tunnel/30.30.30.1-20.20.20.1/require;
>>spdadd 192.168.0.0/16 192.168.2.0/24 any -P out ipsec
>>esp/tunnel/20.20.20.1-40.40.40.1/require;
>>spdadd 192.168.2.0/24 192.168.0.0/16 any -P in ipsec
>>esp/tunnel/40.40.40.1-20.20.20.1/require;
>>    
>>
>
>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.
>>Continuing:
>>
>>On the Branch #1:
>>spdadd 192.168.1.0/24 192.168.0.0/16 any -P out ipsec
>>esp/tunnel/30.30.30.1-20.20.20.1/require;
>>spdadd 192.168.0.0/16 192.168.1.0/24 any -P in ipsec
>>esp/tunnel/20.20.20.1-30.30.30.1/require;
>>spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
>>esp/tunnel/30.30.30.1-40.40.40.1/require;
>>spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
>>esp/tunnel/40.40.40.1-30.30.30.1/require;
>>
>>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 20.20.20.1 for
>>processing, but still have those that have better-fitting netmasks to go
>>direct.
>>
>>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
>originated at.
>
>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
>private.
>
>As a concrete example (for the branch 1, I added branch #3 at 50.50.50.1):
>
>spdadd 30.30.30.1-20.20.20.1 any -P out ipsec esp/transport//require
>spdadd 20.20.20.1-30.30.30.1 any -P in  ipsec esp/transport//require
>spdadd 30.30.30.1-40.40.40.1 any -P out ipsec esp/transport//require
>spdadd 40.40.40.1-30.30.30.1 any -P in  ipsec esp/transport//require
>spdadd 30.30.30.1-50.50.50.1 any -P out ipsec esp/transport//require
>spdadd 50.50.50.1-30.30.30.1 any -P in  ipsec eps/transport//require
>  
>
So this means that any traffic coming from 30.30.30.1 to 20.20.20.1 
(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:
>
>ifconfig.gif0
>create				#automatically create the interface
>inet tunnel 30.30.30.1 20.20.20.1
>inet 192.168.1.1 192.168.0.1
>
>ifconfig.gif1
>create
>inet tunnel 30.30.30.1 40.40.40.1
>inet 192.168.1.1 192.168.2.1
>
>ifconfig.gif2
>create
>inet tunnel 30.30.30.1 50.50.50.1
>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, 30.30.30.1), 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 
that on?

Thanks again so much!