Subject: Re: IPSec question - regarding esp/tunnel mode.
To: J. Buck Caldwell <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/13/2003 12:14:01
On Sun, 13 Jul 2003, J. Buck Caldwell wrote:
> 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:
> >>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
> >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 188.8.131.52):
> >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 esp/transport//require
> >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 eps/transport//require
> So this means that any traffic coming from 184.108.40.206 to 220.127.116.11
> (etc) will be encrypted, and it doesn't pay attention to the
> already-translated address, right?
So _any_ branch's traffic can come over that pipe. From what I gather,
that matches your trust model.
One interesting thing about the technique I'm suggesting is that you'll
get packets that look the same as ESP/tunnel packets. The big difference
is the policy difference above.
> >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 18.104.22.168 22.214.171.124
> >inet 192.168.1.1 192.168.0.1
> >inet tunnel 126.96.36.199 188.8.131.52
> >inet 192.168.1.1 192.168.2.1
> >inet tunnel 184.108.40.206 220.127.116.11
> >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, 18.104.22.168), 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.
Yes. But that's a property of what they are; all traffic from net X is
exchanged with a certain other router (other end of tunnel), so your
routing is fixed. :-)
> 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?
No, that'd be a separate step. I've never actually enabled compression..
> Thanks again so much!