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 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.

> 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

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.

Take care,

Bill