Date: Fri, 02 Aug 2002 10:02:38 -0500 From: "Matthew Grooms" <mgrooms@seton.org> To: <cjc@FreeBSD.org>, <freebsd-security@FreeBSD.org> Subject: Re: esp tunnel without gif(4) [Was Re: vpn1/fw1 NG to ipsec/racoontroubles, help please ...] Message-ID: <sd4a58ca.054@aus-gwia.aus.dcnhs.org>
next in thread | raw e-mail | index | archive | help
Eric,
How traffic will be routed is defined by your near/far encryption
domains that were configured via setkey/spdadd directives. These src/dst
domains are compared to packet src/dst to determine if they need to be
encrypted. The IPSEC peer gateway is also defined for each spdadd so
that your gateway knows where to forward the packets after the
ecrypt/encap step.
This works a bit different for gif enabled tunnels because the IPSEC
peer gateways are actually defined by the private tunnel interface end
points, not the publicly routable interfaces. Its also possible to use a
mixture if giff'd and 'vanila' ESP tunnels. I am doing this right now so
I have attached my config script as an example.
<snip>
echo Initializing IPSEC security policies ...
# create tunnel device
ifconfig gif0 create 2> /dev/null
# public addresses ( external )
gifconfig gif0 66.90.146.202 66.68.118.215
# private addresses ( internal )
ifconfig gif0 inet 10.22.200.1 10.1.2.1 netmask 255.255.255.0
# delete all existing SPD and SAD entries
setkey -FP
setkey -F
setkey -c << EOF
spdadd 10.22.200.0/24 10.1.2.0/24 any -P out ipsec
esp/tunnel/10.22.200.1-10.1.2.1/require;
spdadd 10.1.2.0/24 10.22.200.0/24 any -P in ipsec
esp/tunnel/10.1.2.1-10.22.200.1/require;
spdadd 10.22.200.0/24 10.20.0.0/16 any -P out ipsec
esp/tunnel/66.90.146.202-65.118.63.252/require;
spdadd 10.20.0.0/16 10.22.200.0/24 any -P in ipsec
esp/tunnel/65.118.63.252-66.90.146.202/require;
spdadd 10.22.200.0/24 10.21.0.0/16 any -P out ipsec
esp/tunnel/66.90.146.202-65.118.63.252/require;
spdadd 10.21.0.0/16 10.22.200.0/24 any -P in ipsec
esp/tunnel/65.118.63.252-66.90.146.202/require;
spdadd 10.22.200.0/24 10.23.0.0/16 any -P out ipsec
esp/tunnel/66.90.146.202-65.118.63.252/require;
spdadd 10.23.0.0/16 10.22.200.0/24 any -P in ipsec
esp/tunnel/65.118.63.252-66.90.146.202/require;
EOF
echo Restarting IKE daemon ...
killall racoon 2> /dev/null
sleep 1
/usr/local/sbin/racoon -l /var/log/racoon.log -v
</snip>
I hope this answers your question.
-Matthew
>>> Eric Masson <e-masson@kisoft-services.com> 08/02/02 08:07 AM >>>
>>>>> "Emss" == Eric Masson <e-masson@kisoft-services.com> writes:
>>>>> "Crist" == Crist J Clark <crist.clark@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 majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sd4a58ca.054>