esp tunnel without gif(4) [Was Re: vpn1/fw1 NG to ipsec/racoon troubles, help please ...]
Eric Masson
>>>>> "Crist" == Crist J Clark <crist...@attbi.com> writes:
Follow-up to myself and -security re-added.
Crist> I've never figured out why people use gif(4) interfaces when ESP
Crist> does the tunneling for you.
Emss> Maybe because I've never succeeded establishing a esp tunnel
Emss> beetween two lans without gif(4).
I've tried without gif tunnel (erroneous rc.conf modification) and it
works, maybe murphy's law had prevented this before ;)
There's one question still remaining :
- if there are more than one esp tunnel configured, how is traffic
routed ?
Example :
- One esp tunnel from 192.168.0.1 to 10.93.0.1
- One esp tunnel from 192.168.0.1 to 10.44.0.1
With only one tunnel configured, netstat -rn on the security gateway
doesn't show any routes to the remote networks nor host.
With a second tunnel added, are there any additionnal configuration
steps or will the kernel do the routing automagically ?
Links or example setup if needed ?
Thanks in advance
Eric Masson
--
Bref, j'en ai lu des conneries dans fufe, j'en ai même écrit, mais là,
on flirte avec le ruban bleu.
-+- RM in : <http://www.le-gnu.net> - Ca mérite le GNUban bleu -+-
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Crist J. Clark
> >>>>> "Emss" == Eric Masson <e-ma...@kisoft-services.com> writes:
> >>>>> "Crist" == Crist J Clark <crist...@attbi.com> writes:
>
> Follow-up to myself and -security re-added.
>
> Crist> I've never figured out why people use gif(4) interfaces when ESP
> Crist> does the tunneling for you.
>
> Emss> Maybe because I've never succeeded establishing a esp tunnel
> Emss> beetween two lans without gif(4).
>
> I've tried without gif tunnel (erroneous rc.conf modification) and it
> works, maybe murphy's law had prevented this before ;)
>
> There's one question still remaining :
> - if there are more than one esp tunnel configured, how is traffic
> routed ?
>
> Example :
> - One esp tunnel from 192.168.0.1 to 10.93.0.1
> - One esp tunnel from 192.168.0.1 to 10.44.0.1
>
> With only one tunnel configured, netstat -rn on the security gateway
> doesn't show any routes to the remote networks nor host.
>
> With a second tunnel added, are there any additionnal configuration
> steps or will the kernel do the routing automagically ?
It's pretty much automagically done by way of the SPD entry. Any
packet that matches the source and destination in the SPD gets put
through the appropriate tunnel with the specified end points. It's not
the same as the regular routing table and will not show up in 'netstat
-rn.'
--
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org
Nicholas Esborn
> On Fri, Aug 02, 2002 at 02:56:39PM +0200, Eric Masson wrote:
> > With only one tunnel configured, netstat -rn on the security gateway
> > doesn't show any routes to the remote networks nor host.
> >
> > With a second tunnel added, are there any additionnal configuration
> > steps or will the kernel do the routing automagically ?
>
> It's pretty much automagically done by way of the SPD entry. Any
> packet that matches the source and destination in the SPD gets put
> through the appropriate tunnel with the specified end points. It's not
> the same as the regular routing table and will not show up in 'netstat
> -rn.'
I ended up using AH and ESP in transport mode between gateways, then using
gif tunnels to encapsulate traffic to other networks. I wanted to be able
to use the routing table. I never liked tunnel mode IPsec's "magic portal"
approach.
> --
> Crist J. Clark | cjc...@alum.mit.edu
> | cjc...@jhu.edu
> http://people.freebsd.org/~cjc/ | c...@freebsd.org
-nick
--
Nicholas Esborn
Unix Systems Administrator
Berkeley, California
Eric Masson
Crist> It's pretty much automagically done by way of the SPD entry. Any
Crist> packet that matches the source and destination in the SPD gets
Crist> put through the appropriate tunnel with the specified end
Crist> points.
Ok, I do understand now.
Crist> It's not the same as the regular routing table and will not show
Crist> up in 'netstat -rn.'
It would be nice to have netstat -r show these routes with a new flag
(like T for example), tunnelled end address as destination, tunneled
origin address as gateway, and interface bound to tunnel origin address
as netif.
Does this look interesting or is this plain dumb ?
Eric Masson
--
> dvips -o $@ $<
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-
Mike Tancsa
> Crist> It's not the same as the regular routing table and will not show
> Crist> up in 'netstat -rn.'
>
>It would be nice to have netstat -r show these routes with a new flag
>(like T for example), tunnelled end address as destination, tunneled
>origin address as gateway, and interface bound to tunnel origin address
>as netif.
>
>Does this look interesting or is this plain dumb ?
Something like this would make things much more clear IMHO.
---Mike
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
Crist J. Clark
> >>>>> "Crist" == Crist J Clark <crist...@attbi.com> writes:
>
> Crist> It's pretty much automagically done by way of the SPD entry. Any
> Crist> packet that matches the source and destination in the SPD gets
> Crist> put through the appropriate tunnel with the specified end
> Crist> points.
>
> Ok, I do understand now.
>
> Crist> It's not the same as the regular routing table and will not show
> Crist> up in 'netstat -rn.'
>
> It would be nice to have netstat -r show these routes with a new flag
> (like T for example), tunnelled end address as destination, tunneled
> origin address as gateway, and interface bound to tunnel origin address
> as netif.
>
> Does this look interesting or is this plain dumb ?
Tunnelling is not the same as routing. The tunnelling actually has no
effect on routing. A packet going through the tunnel is encapsulated
and sent to a different destination. This is not like routing where we
don't touch the source or destination addresses and merely manipulate
where the packet is directed on the next hop. Once encapsulation is
done, routing is done normally.
Another place for confusion, what do you display for,
spdadd 10.10.10.0/24[any] 10.99.99.0/24[25] tcp
-P out ipsec esp/tunnel/10.10.11.1-10.99.98.1/require
Where not all traffic, but only some, goes through the tunnel. (Yes,
an odd use of tunnelling, but perfectly valid.)
I think trying to add IPsec tunnels to 'netstat -r' is not a good
idea. 'netstat -r' should show the routing table and nothing more.
I think a command that displays the SPD and live SAD entries in more
intuitive ways, possibly in a 'netstat -r'-like fashion would be very
useful, but it shouldn't actually be in 'netstat -r.'
--
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org
To Unsubscribe: send mail to majo...@FreeBSD.org