Index the Firewall chapter and the IPsec section.
Instead of "user configuration files" explicitly list the files ".k5login" and ".k5users".
This commit is contained in:
parent
5a1b1754e3
commit
45ade4e6e9
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=23730
4 changed files with 273 additions and 6 deletions
en_US.ISO8859-1/books/handbook
|
@ -1817,7 +1817,7 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
<sect3>
|
||||
<title>Filtering/Traffic Shaping Firewall</title>
|
||||
<indexterm><primary>firewall</primary></indexterm>
|
||||
<indexterm><primary>network address translation</primary></indexterm>
|
||||
<indexterm><primary>NAT</primary></indexterm>
|
||||
|
||||
<para>The second common situation is where firewall functionality is
|
||||
needed without network address translation (NAT).</para>
|
||||
|
@ -3029,7 +3029,7 @@ ISDN BRI line</literallayout>
|
|||
it is able to determine the original location of the data and forward
|
||||
it back to its original requester.</para>
|
||||
<indexterm><primary>Internet connection sharing</primary></indexterm>
|
||||
<indexterm><primary>IP masquerading</primary></indexterm>
|
||||
<indexterm><primary>NAT</primary></indexterm>
|
||||
<para>The most common use of NAT is to perform what is commonly known as
|
||||
Internet Connection Sharing.</para>
|
||||
</sect2>
|
||||
|
|
|
@ -111,6 +111,11 @@
|
|||
<sect1 id="firewalls-concepts">
|
||||
<title>Firewall Concepts</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>firewall</primary>
|
||||
<secondary>rulesets</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>There are two basic ways to create firewall rulesets:
|
||||
<quote>inclusive</quote> or <quote>exclusive</quote>. An
|
||||
exclusive firewall allows all traffic through except for the
|
||||
|
@ -193,6 +198,11 @@
|
|||
<sect1 id="firewalls-pf">
|
||||
<title>The Packet Filter (PF) Firewall</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>firewall</primary>
|
||||
<secondary>PF</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>As of July 2003 the OpenBSD firewall software application
|
||||
known as <acronym>PF</acronym> was ported to &os; and was made
|
||||
available in the &os; ports collection; the first release that
|
||||
|
@ -280,6 +290,22 @@
|
|||
|
||||
<sect2>
|
||||
<title>Kernel options</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>device pf</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>device pflog</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>device pfsync</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>It is not a mandatory requirement that you enable PF by
|
||||
compiling the following options into the &os; kernel. It is only
|
||||
presented here as background information. Compiling PF into the
|
||||
|
@ -335,6 +361,11 @@ pflog_flags="" # additional flags for pflogd startup</programli
|
|||
<sect1 id="firewalls-ipf">
|
||||
<title>The IPFILTER (IPF) Firewall</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>firewall</primary>
|
||||
<secondary>IPFILTER</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The author of IPFILTER is Darren Reed. IPFILTER is not
|
||||
operating system dependent: it is an open source
|
||||
application and has been ported to &os;, NetBSD, OpenBSD, SunOS,
|
||||
|
@ -388,6 +419,12 @@ pflog_flags="" # additional flags for pflogd startup</programli
|
|||
|
||||
<sect2>
|
||||
<title>Enabling IPF</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>enabling</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>IPF is included in the basic &os; install as a separate
|
||||
run time loadable module. The system will dynamically load the IPF kernel
|
||||
loadable module when the rc.conf statement <literal>
|
||||
|
@ -401,6 +438,27 @@ pflog_flags="" # additional flags for pflogd startup</programli
|
|||
|
||||
<sect2>
|
||||
<title>Kernel options</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFILTER</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFILTER_LOG</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFILTER_DEFAULT_BLOCK</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>kernel options</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>It is not a mandatory requirement that you enable IPF by
|
||||
compiling the following options into the &os; kernel. It is
|
||||
only presented here as background information. Compiling IPF
|
||||
|
@ -456,6 +514,11 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
|
|||
|
||||
<sect2>
|
||||
<title>IPF</title>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>ipf</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>The ipf command is used to load your rules file. Normally
|
||||
you create a file containing your custom rules and use this
|
||||
command to replace in mass the currently running firewall
|
||||
|
@ -487,6 +550,16 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
|
|||
|
||||
<sect2>
|
||||
<title>IPFSTAT</title>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>ipfstat</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>statistics</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The default behavior of &man.ipfstat.8; is to retrieve and
|
||||
display the totals of the accumulated statistics gathered as a
|
||||
result of applying the user coded rules against packets going
|
||||
|
@ -563,6 +636,16 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
|
|||
<sect2>
|
||||
|
||||
<title>IPMON</title>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>ipmon</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>logging</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>In order for <command>ipmon</command> to work properly, the
|
||||
kernel option IPFILTER_LOG must be turned on. This command has
|
||||
two different modes that it can be used in. Native mode is the default
|
||||
|
@ -825,6 +908,11 @@ sh /etc/ipf.rules.script</programlisting>
|
|||
number. This is the basic selection criteria used to create
|
||||
rules which will pass or block services.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>rule processing order</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>IPF was originally written using a rules processing logic
|
||||
of <quote>the last matching rule wins</quote> and used only stateless
|
||||
rules. Over time IPF has been enhanced to include a <quote>quick</quote>
|
||||
|
@ -859,6 +947,12 @@ sh /etc/ipf.rules.script</programlisting>
|
|||
|
||||
<sect2>
|
||||
<title>Rule Syntax</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>rule syntax</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The rule syntax presented here has been simplified to only
|
||||
address the modern stateful rule context and <quote>first matching
|
||||
rule wins</quote> logic. For the complete legacy rule syntax
|
||||
|
@ -1086,6 +1180,12 @@ sh /etc/ipf.rules.script</programlisting>
|
|||
|
||||
<sect2>
|
||||
<title>Stateful Filtering</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFILTER</primary>
|
||||
<secondary>stateful filtering</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Stateful filtering treats traffic as a bi-directional
|
||||
exchange of packets comprising a session conversation. When
|
||||
activated, keep-state dynamically generates internal rules for
|
||||
|
@ -1403,6 +1503,20 @@ block in log first quick on dc0 all
|
|||
<sect2>
|
||||
<title><acronym>NAT</acronym></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>NAT</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IP masquerading</primary>
|
||||
<see>NAT</see>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>network address translation</primary>
|
||||
<see>NAT</see>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>NAT</acronym> stands for Network Address
|
||||
Translation. To those familiar with Linux, this concept is
|
||||
called IP Masquerading; <acronym>NAT</acronym> and IP
|
||||
|
@ -1486,6 +1600,15 @@ block in log first quick on dc0 all
|
|||
<sect2>
|
||||
<title>IP<acronym>NAT</acronym></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>NAT</primary>
|
||||
<secondary>and IPFILTER</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>ipnat</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>NAT</acronym> rules are loaded by using the <command>ipnat</command>
|
||||
command. Typically the <acronym>NAT</acronym> rules are stored
|
||||
in <filename>/etc/ipnat.rules</filename>. See &man.ipnat.1
|
||||
|
@ -1786,6 +1909,11 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
|
|||
<sect1 id="firewalls-ipfw">
|
||||
<title>IPFW</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>firewall</primary>
|
||||
<secondary>IPFW</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The IPFIREWALL (IPFW) is a &os; sponsored firewall software
|
||||
application authored and maintained by &os; volunteer staff
|
||||
members. It uses the legacy stateless rules and a legacy rule
|
||||
|
@ -1814,6 +1942,11 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
|
|||
<sect2 id="firewalls-ipfw-enable">
|
||||
<title>Enabling IPFW</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>enabling</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>IPFW is included in the basic &os; install as a separate
|
||||
run time loadable module. The system will dynamically load the
|
||||
kernel module when the <filename>rc.conf</filename> statement
|
||||
|
@ -1845,6 +1978,26 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
|
|||
<sect2 id="firewalls-ipfw-kernel">
|
||||
<title>Kernel Options</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFIREWALL</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFIREWALL_VERBOSE</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFIREWALL_VERBOSE_LIMIT</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>kernel options</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>It is not a mandatory requirement that you enable IPFW by
|
||||
compiling the following options into the &os; kernel unless
|
||||
you need <acronym>NAT</acronym> function. It is presented here
|
||||
|
@ -1869,6 +2022,11 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
|
|||
number of consecutive times to log evidence of this unique
|
||||
occurrence.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPFIREWALL_DEFAULT_TO_ACCEPT</secondary>
|
||||
</indexterm>
|
||||
|
||||
<programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
||||
|
||||
<para>This option will allow everything to pass through the
|
||||
|
@ -1884,6 +2042,11 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
they are for IPv6. If you do not use IPv6 you might want to use
|
||||
IPV6FIREWALL without any rules to block all IPv6</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPDIVERT</secondary>
|
||||
</indexterm>
|
||||
|
||||
<programlisting>options IPDIVERT</programlisting>
|
||||
|
||||
<para>This enables the use of <acronym>NAT</acronym>
|
||||
|
@ -1917,6 +2080,10 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
<sect2 id="firewalls-ipfw-cmd">
|
||||
<title>The IPFW Command</title>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>ipfw</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>The ipfw command is the normal vehicle for making manual
|
||||
single rule additions or deletions to the firewall active
|
||||
internal rules while it is running. The problem with using
|
||||
|
@ -1984,6 +2151,11 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
This is the basic selection criteria used to create rules
|
||||
which will allow or deny services.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>rule processing order</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>When a packet enters the firewall it is compared against
|
||||
the first rule in the rule set and progress one rule at a time
|
||||
moving from top to bottom of the set in ascending rule number
|
||||
|
@ -2018,6 +2190,11 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
<sect3 id="firewalls-ipfw-rules-syntax">
|
||||
<title>Rule Syntax</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>rule syntax</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The rule syntax presented here has been simplified to
|
||||
what is necessary to create a standard inclusive type
|
||||
firewall rule set. For a complete rule syntax description
|
||||
|
@ -2185,6 +2362,11 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
<sect3>
|
||||
<title>Stateful Rule Option</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>stateful filtering</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Stateful filtering treats traffic as a bi-directional
|
||||
exchange of packets comprising a session conversation. It
|
||||
has the interrogation abilities to determine if the session
|
||||
|
@ -2219,6 +2401,12 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
|
|||
|
||||
<sect3>
|
||||
<title>Logging Firewall Messages</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPFW</primary>
|
||||
<secondary>logging</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The benefits of logging are obvious: it provides the
|
||||
ability to review after the fact the rules you activated
|
||||
logging on which provides information like, what packets had
|
||||
|
@ -2598,6 +2786,12 @@ pif="dc0" # public interface name of NIC
|
|||
|
||||
<sect3>
|
||||
<title>An Example <acronym>NAT</acronym> and Stateful Ruleset</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>NAT</primary>
|
||||
<secondary>and IPFW</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>There are some additional configuration statements that
|
||||
need to be enabled to activate the <acronym>NAT</acronym> function of IPFW. The
|
||||
kernel source needs 'option divert' statement added to the
|
||||
|
|
|
@ -275,7 +275,7 @@
|
|||
</listitem>
|
||||
|
||||
<indexterm><primary>firewall</primary></indexterm>
|
||||
<indexterm><primary>IP masquerading</primary></indexterm>
|
||||
<indexterm><primary>NAT</primary></indexterm>
|
||||
<listitem>
|
||||
<para>Firewalls and NAT (<quote>IP masquerading</quote>)
|
||||
gateways</para>
|
||||
|
|
|
@ -2610,8 +2610,11 @@ kadmin><userinput> exit</userinput></screen>
|
|||
<title>User configuration files: <filename>.k5login</filename> and <filename>.k5users</filename></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>Kerberos5</primary>
|
||||
<secondary>user configuration files</secondary>
|
||||
<primary><filename>.k5login</filename></primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary><filename>.k5users</filename></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Users within a realm typically have their
|
||||
|
@ -3177,6 +3180,10 @@ Connection closed by foreign host.</screen>
|
|||
</authorgroup>
|
||||
</sect1info>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPsec</primary>
|
||||
</indexterm>
|
||||
|
||||
<title>VPN over IPsec</title>
|
||||
<para>Creating a VPN between two networks, separated by the
|
||||
Internet, using FreeBSD gateways.</para>
|
||||
|
@ -3225,6 +3232,11 @@ Connection closed by foreign host.</screen>
|
|||
kernel option has to be added to your kernel configuration
|
||||
file:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>FAST_IPSEC</secondary>
|
||||
</indexterm>
|
||||
|
||||
<screen>
|
||||
options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)
|
||||
</screen>
|
||||
|
@ -3236,6 +3248,16 @@ options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)
|
|||
|
||||
</note>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPsec</primary>
|
||||
<secondary>ESP</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPsec</primary>
|
||||
<secondary>AH</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>IPsec consists of two sub-protocols:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
@ -3261,6 +3283,15 @@ options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)
|
|||
either be used together or separately, depending on the
|
||||
environment.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>VPN</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>virtual private network</primary>
|
||||
<see>VPN</see>
|
||||
</indexterm>
|
||||
|
||||
<para>IPsec can either be used to directly encrypt the traffic
|
||||
between two hosts (known as <emphasis>Transport
|
||||
Mode</emphasis>); or to build <quote>virtual tunnels</quote>
|
||||
|
@ -3273,12 +3304,27 @@ options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)
|
|||
|
||||
<para>To add IPsec support to your kernel, add the following
|
||||
options to your kernel configuration file:</para>
|
||||
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC_ESP</secondary>
|
||||
</indexterm>
|
||||
|
||||
<screen>
|
||||
options IPSEC #IP security
|
||||
options IPSEC_ESP #IP security (crypto; define w/ IPSEC)
|
||||
</screen>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC_DEBUG</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>If IPsec debugging support is desired, the following
|
||||
kernel option should also be added:</para>
|
||||
|
||||
|
@ -3301,6 +3347,11 @@ options IPSEC_DEBUG #debug for IP security
|
|||
<title>The Scenario: Two networks, connected to the Internet, to
|
||||
behave as one</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>VPN</primary>
|
||||
<secondary>creating</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The premise is as follows:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
@ -3696,6 +3747,11 @@ route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
|
|||
kernel to support IPsec and the Encapsulated Security Payload
|
||||
(ESP) protocol. This is done by configuring a kernel with:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC</secondary>
|
||||
</indexterm>
|
||||
|
||||
<programlisting>options IPSEC
|
||||
options IPSEC_ESP
|
||||
</programlisting>
|
||||
|
@ -3704,6 +3760,10 @@ options IPSEC_ESP
|
|||
you will need to do this to the kernels on both of the gateway
|
||||
hosts.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>IKE</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>You have two choices when it comes to setting up security
|
||||
associations. You can configure them by hand between two hosts,
|
||||
which entails choosing the encryption algorithm, encryption keys,
|
||||
|
@ -3713,6 +3773,15 @@ options IPSEC_ESP
|
|||
<para>I recommend the latter. Apart from anything else, it is
|
||||
easier to set up.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>IPsec</primary>
|
||||
<secondary>security policies</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>setkey</command></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Editing and displaying security policies is carried out
|
||||
using &man.setkey.8;. By analogy, <command>setkey</command> is
|
||||
to the kernel's security policy tables as &man.route.8; is to
|
||||
|
@ -3727,6 +3796,10 @@ options IPSEC_ESP
|
|||
collection, in the security/ category, and is installed in the
|
||||
usual way.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>racoon</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>racoon must be run on both gateway hosts. On each host it
|
||||
is configured with the IP address of the other end of the VPN,
|
||||
and a secret key (which you choose, and must be the same on both
|
||||
|
|
Loading…
Reference in a new issue