White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
parent
1feff8b3ea
commit
376d565530
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44631
1 changed files with 198 additions and 190 deletions
|
|
@ -1993,7 +1993,8 @@ Connection closed by foreign host.</screen>
|
|||
|
||||
<sect1 xml:id="ipsec">
|
||||
<info>
|
||||
<title><acronym>VPN</acronym> over <acronym>IPsec</acronym></title>
|
||||
<title><acronym>VPN</acronym> over
|
||||
<acronym>IPsec</acronym></title>
|
||||
|
||||
<authorgroup>
|
||||
<author><personname><firstname>Nik</firstname><surname>Clayton</surname></personname><affiliation>
|
||||
|
|
@ -2012,183 +2013,190 @@ Connection closed by foreign host.</screen>
|
|||
<primary><acronym>IPsec</acronym></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Internet Protocol Security (<acronym>IPsec</acronym>) is a set of protocols which sit on
|
||||
top of the Internet Protocol (<acronym>IP</acronym>) layer.
|
||||
It allows two or more hosts to communicate in a secure manner
|
||||
by authenticating and encrypting each <acronym>IP</acronym> packet of a communication session.
|
||||
The &os; <acronym>IPsec</acronym> network stack is based on the
|
||||
<link xlink:href="http://www.kame.net/">http://www.kame.net/</link>
|
||||
implementation and supports both <acronym>IPv4</acronym> and
|
||||
<acronym>IPv6</acronym> sessions.</para>
|
||||
<para>Internet Protocol Security (<acronym>IPsec</acronym>) is a
|
||||
set of protocols which sit on top of the Internet Protocol
|
||||
(<acronym>IP</acronym>) layer. It allows two or more hosts to
|
||||
communicate in a secure manner by authenticating and encrypting
|
||||
each <acronym>IP</acronym> packet of a communication session.
|
||||
The &os; <acronym>IPsec</acronym> network stack is based on the
|
||||
<link
|
||||
xlink:href="http://www.kame.net/">http://www.kame.net/</link>
|
||||
implementation and supports both <acronym>IPv4</acronym> and
|
||||
<acronym>IPv6</acronym> sessions.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><acronym>IPsec</acronym></primary>
|
||||
<secondary>ESP</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary><acronym>IPsec</acronym></primary>
|
||||
<secondary>ESP</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary><acronym>IPsec</acronym></primary>
|
||||
<secondary>AH</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary><acronym>IPsec</acronym></primary>
|
||||
<secondary>AH</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>IPsec</acronym> is comprised of the following sub-protocols:</para>
|
||||
<para><acronym>IPsec</acronym> is comprised of the following
|
||||
sub-protocols:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>Encapsulated Security Payload
|
||||
(<acronym>ESP</acronym>)</emphasis>: this protocol
|
||||
protects the <acronym>IP</acronym> packet data from third party interference
|
||||
by encrypting the contents using symmetric cryptography
|
||||
algorithms such as Blowfish and <acronym>3DES</acronym>.</para>
|
||||
</listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>Encapsulated Security Payload
|
||||
(<acronym>ESP</acronym>)</emphasis>: this protocol protects
|
||||
the <acronym>IP</acronym> packet data from third party
|
||||
interference by encrypting the contents using symmetric
|
||||
cryptography algorithms such as Blowfish and
|
||||
<acronym>3DES</acronym>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Authentication Header
|
||||
(<acronym>AH</acronym>)</emphasis>): this protocol
|
||||
protects the <acronym>IP</acronym> packet header from third party
|
||||
interference and spoofing by computing a cryptographic
|
||||
checksum and hashing the <acronym>IP </acronym> packet header fields with a
|
||||
secure hashing function. This is then followed by an
|
||||
additional header that contains the hash, to allow the
|
||||
information in the packet to be authenticated.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Authentication Header
|
||||
(<acronym>AH</acronym>)</emphasis>): this protocol protects
|
||||
the <acronym>IP</acronym> packet header from third party
|
||||
interference and spoofing by computing a cryptographic
|
||||
checksum and hashing the <acronym>IP </acronym> packet
|
||||
header fields with a secure hashing function. This is then
|
||||
followed by an additional header that contains the hash, to
|
||||
allow the information in the packet to be
|
||||
authenticated.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>IP Payload Compression Protocol
|
||||
(<acronym>IPComp</acronym></emphasis>): this protocol
|
||||
tries to increase communication performance by compressing
|
||||
the <acronym>IP </acronym> payload in order ro reduce the
|
||||
amount of data sent.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>IP Payload Compression Protocol
|
||||
(<acronym>IPComp</acronym></emphasis>): this protocol tries
|
||||
to increase communication performance by compressing the
|
||||
<acronym>IP </acronym> payload in order ro reduce the
|
||||
amount of data sent.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These protocols can
|
||||
either be used together or separately, depending on the
|
||||
environment.</para>
|
||||
<para>These protocols can either be used together or separately,
|
||||
depending on the environment.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><acronym>VPN</acronym></primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary><acronym>VPN</acronym></primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>virtual private network</primary>
|
||||
<see>VPN</see>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>virtual private network</primary>
|
||||
<see>VPN</see>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>IPsec</acronym> supports two modes of operation.
|
||||
The first mode, <firstterm>Transport Mode</firstterm>,
|
||||
protects communications between two hosts. The second mode,
|
||||
<firstterm>Tunnel Mode</firstterm>, is used to build virtual tunnels,
|
||||
commonly known as Virtual Private Networks
|
||||
(<acronym>VPN</acronym>s). Consult &man.ipsec.4;
|
||||
for detailed information on the <acronym>IPsec</acronym> subsystem in
|
||||
&os;.</para>
|
||||
<para><acronym>IPsec</acronym> supports two modes of operation.
|
||||
The first mode, <firstterm>Transport Mode</firstterm>, protects
|
||||
communications between two hosts. The second mode,
|
||||
<firstterm>Tunnel Mode</firstterm>, is used to build virtual
|
||||
tunnels, commonly known as Virtual Private Networks
|
||||
(<acronym>VPN</acronym>s). Consult &man.ipsec.4; for detailed
|
||||
information on the <acronym>IPsec</acronym> subsystem in
|
||||
&os;.</para>
|
||||
|
||||
<para>To add <acronym>IPsec</acronym> support to the kernel, add the following
|
||||
options to the custom kernel configuration file and rebuild
|
||||
the kernel using the instructions in <xref linkend="kernelconfig"/>:</para>
|
||||
<para>To add <acronym>IPsec</acronym> support to the kernel, add
|
||||
the following options to the custom kernel configuration file
|
||||
and rebuild the kernel using the instructions in <xref
|
||||
linkend="kernelconfig"/>:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC</secondary>
|
||||
</indexterm>
|
||||
|
||||
<screen>options IPSEC #IP security
|
||||
<screen>options IPSEC #IP security
|
||||
device crypto</screen>
|
||||
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC_DEBUG</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>kernel options</primary>
|
||||
<secondary>IPSEC_DEBUG</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>If <acronym>IPsec</acronym> debugging support is desired, the following
|
||||
kernel option should also be added:</para>
|
||||
<para>If <acronym>IPsec</acronym> debugging support is desired,
|
||||
the following kernel option should also be added:</para>
|
||||
|
||||
<screen>options IPSEC_DEBUG #debug for IP security</screen>
|
||||
<screen>options IPSEC_DEBUG #debug for IP security</screen>
|
||||
|
||||
<para>This rest of this chapter demonstrates the process of
|
||||
setting up an <acronym>IPsec</acronym> <acronym>VPN</acronym>
|
||||
between a home network and a corporate
|
||||
network. In the example scenario:</para>
|
||||
<para>This rest of this chapter demonstrates the process of
|
||||
setting up an <acronym>IPsec</acronym> <acronym>VPN</acronym>
|
||||
between a home network and a corporate network. In the example
|
||||
scenario:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Both sites are connected to the Internet through a
|
||||
gateway that is running &os;.</para>
|
||||
</listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Both sites are connected to the Internet through a
|
||||
gateway that is running &os;.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The gateway on each network has at least one external
|
||||
<acronym>IP</acronym> address. In this example, the corporate <acronym>LAN</acronym>'s
|
||||
external <acronym>IP</acronym> address is <systemitem
|
||||
<listitem>
|
||||
<para>The gateway on each network has at least one external
|
||||
<acronym>IP</acronym> address. In this example, the
|
||||
corporate <acronym>LAN</acronym>'s external
|
||||
<acronym>IP</acronym> address is <systemitem
|
||||
class="ipaddress">172.16.5.4</systemitem> and the home
|
||||
<acronym>LAN</acronym>'s external <acronym>IP</acronym>
|
||||
address is <systemitem
|
||||
class="ipaddress">192.168.1.12</systemitem>.</para>
|
||||
</listitem>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The internal addresses of the two networks can be
|
||||
either public or private <acronym>IP</acronym> addresses. However, the
|
||||
address space must not collide. For example, both
|
||||
networks cannot use <systemitem
|
||||
class="ipaddress">192.168.1.x</systemitem>. In this
|
||||
example, the corporate <acronym>LAN</acronym>'s
|
||||
internal <acronym>IP</acronym> address is <systemitem
|
||||
<listitem>
|
||||
<para>The internal addresses of the two networks can be either
|
||||
public or private <acronym>IP</acronym> addresses. However,
|
||||
the address space must not collide. For example, both
|
||||
networks cannot use <systemitem
|
||||
class="ipaddress">192.168.1.x</systemitem>. In this
|
||||
example, the corporate <acronym>LAN</acronym>'s internal
|
||||
<acronym>IP</acronym> address is <systemitem
|
||||
class="ipaddress">10.246.38.1</systemitem> and the home
|
||||
<acronym>LAN</acronym>'s internal <acronym>IP</acronym>
|
||||
address is <systemitem class="ipaddress">10.0.0.5</systemitem>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
address is <systemitem
|
||||
class="ipaddress">10.0.0.5</systemitem>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2>
|
||||
<info>
|
||||
<title>Configuring a <acronym>VPN</acronym> on &os;</title>
|
||||
<sect2>
|
||||
<info>
|
||||
<title>Configuring a <acronym>VPN</acronym> on &os;</title>
|
||||
|
||||
<authorgroup>
|
||||
<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><affiliation>
|
||||
<address><email>trhodes@FreeBSD.org</email></address>
|
||||
</affiliation><contrib>Written by </contrib></author>
|
||||
</authorgroup>
|
||||
</info>
|
||||
</info>
|
||||
|
||||
<para>To begin, <package>security/ipsec-tools</package>
|
||||
must be installed from the Ports Collection. This software
|
||||
provides a number of applications which support the
|
||||
configuration.</para>
|
||||
<para>To begin, <package>security/ipsec-tools</package> must be
|
||||
installed from the Ports Collection. This software provides a
|
||||
number of applications which support the configuration.</para>
|
||||
|
||||
<para>The next requirement is to create two &man.gif.4;
|
||||
pseudo-devices which will be used to tunnel packets and
|
||||
allow both networks to communicate properly. As <systemitem
|
||||
class="username">root</systemitem>, run the following
|
||||
commands, replacing <replaceable>internal</replaceable> and
|
||||
<replaceable>external</replaceable> with the real IP
|
||||
addresses of the internal and external interfaces of the two
|
||||
gateways:</para>
|
||||
<para>The next requirement is to create two &man.gif.4;
|
||||
pseudo-devices which will be used to tunnel packets and allow
|
||||
both networks to communicate properly. As <systemitem
|
||||
class="username">root</systemitem>, run the following
|
||||
commands, replacing <replaceable>internal</replaceable> and
|
||||
<replaceable>external</replaceable> with the real IP
|
||||
addresses of the internal and external interfaces of the two
|
||||
gateways:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>ifconfig gif0 create</userinput>
|
||||
<screen>&prompt.root; <userinput>ifconfig gif0 create</userinput>
|
||||
&prompt.root; <userinput>ifconfig gif0 <replaceable>internal1 internal2</replaceable></userinput>
|
||||
&prompt.root; <userinput>ifconfig gif0 tunnel <replaceable>external1 external2</replaceable></userinput></screen>
|
||||
|
||||
<para>Verify the setup on each gateway, using
|
||||
<command>ifconfig</command>. Here is the output from Gateway 1:</para>
|
||||
<para>Verify the setup on each gateway, using
|
||||
<command>ifconfig</command>. Here is the output from Gateway
|
||||
1:</para>
|
||||
|
||||
<programlisting>gif0: flags=8051 mtu 1280
|
||||
<programlisting>gif0: flags=8051 mtu 1280
|
||||
tunnel inet 172.16.5.4 --> 192.168.1.12
|
||||
inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
|
||||
inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00</programlisting>
|
||||
|
||||
<para>Here is the output from Gateway 2:</para>
|
||||
<para>Here is the output from Gateway 2:</para>
|
||||
|
||||
<programlisting>gif0: flags=8051 mtu 1280
|
||||
<programlisting>gif0: flags=8051 mtu 1280
|
||||
tunnel inet 192.168.1.12 --> 172.16.5.4
|
||||
inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
|
||||
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4</programlisting>
|
||||
|
||||
<para>Once complete, both internal <acronym>IP</acronym>
|
||||
addresses should be reachable using &man.ping.8;:</para>
|
||||
<para>Once complete, both internal <acronym>IP</acronym>
|
||||
addresses should be reachable using &man.ping.8;:</para>
|
||||
|
||||
<programlisting>priv-net# ping 10.0.0.5
|
||||
<programlisting>priv-net# ping 10.0.0.5
|
||||
PING 10.0.0.5 (10.0.0.5): 56 data bytes
|
||||
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
|
||||
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
|
||||
|
|
@ -2209,23 +2217,23 @@ PING 10.246.38.1 (10.246.38.1): 56 data bytes
|
|||
5 packets transmitted, 5 packets received, 0% packet loss
|
||||
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms</programlisting>
|
||||
|
||||
<para>As expected, both sides have the ability to send and
|
||||
receive <acronym>ICMP</acronym> packets from the privately
|
||||
configured addresses. Next, both gateways must be told how
|
||||
to route packets in order to correctly send traffic from
|
||||
either network. The following commands will achieve this
|
||||
goal:</para>
|
||||
<para>As expected, both sides have the ability to send and
|
||||
receive <acronym>ICMP</acronym> packets from the privately
|
||||
configured addresses. Next, both gateways must be told how to
|
||||
route packets in order to correctly send traffic from either
|
||||
network. The following commands will achieve this
|
||||
goal:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>corp-net# route add <replaceable>10.0.0.0 10.0.0.5 255.255.255.0</replaceable></userinput>
|
||||
<screen>&prompt.root; <userinput>corp-net# route add <replaceable>10.0.0.0 10.0.0.5 255.255.255.0</replaceable></userinput>
|
||||
&prompt.root; <userinput>corp-net# route add net <replaceable>10.0.0.0: gateway 10.0.0.5</replaceable></userinput>
|
||||
&prompt.root; <userinput>priv-net# route add <replaceable>10.246.38.0 10.246.38.1 255.255.255.0</replaceable></userinput>
|
||||
&prompt.root; <userinput>priv-net# route add host <replaceable>10.246.38.0: gateway 10.246.38.1</replaceable></userinput></screen>
|
||||
|
||||
<para>At this point, internal machines should be reachable
|
||||
from each gateway as well as from machines behind the
|
||||
gateways. Again, use &man.ping.8; to confirm:</para>
|
||||
<para>At this point, internal machines should be reachable from
|
||||
each gateway as well as from machines behind the gateways.
|
||||
Again, use &man.ping.8; to confirm:</para>
|
||||
|
||||
<programlisting>corp-net# ping 10.0.0.8
|
||||
<programlisting>corp-net# ping 10.0.0.8
|
||||
PING 10.0.0.8 (10.0.0.8): 56 data bytes
|
||||
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
|
||||
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
|
||||
|
|
@ -2247,15 +2255,15 @@ PING 10.246.38.1 (10.246.38.107): 56 data bytes
|
|||
5 packets transmitted, 5 packets received, 0% packet loss
|
||||
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms</programlisting>
|
||||
|
||||
<para>Setting up the tunnels is the easy part. Configuring a
|
||||
secure link is a more in depth process. The following
|
||||
configuration uses pre-shared (<acronym>PSK</acronym>)
|
||||
<acronym>RSA</acronym> keys. Other than the
|
||||
<acronym>IP</acronym> addresses, the
|
||||
<filename>/usr/local/etc/racoon/racoon.conf</filename> on
|
||||
both gateways will be identical and look similar to:</para>
|
||||
<para>Setting up the tunnels is the easy part. Configuring a
|
||||
secure link is a more in depth process. The following
|
||||
configuration uses pre-shared (<acronym>PSK</acronym>)
|
||||
<acronym>RSA</acronym> keys. Other than the
|
||||
<acronym>IP</acronym> addresses, the
|
||||
<filename>/usr/local/etc/racoon/racoon.conf</filename> on both
|
||||
gateways will be identical and look similar to:</para>
|
||||
|
||||
<programlisting>path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
|
||||
<programlisting>path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
|
||||
log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete
|
||||
|
||||
padding # options are not to be changed
|
||||
|
|
@ -2313,33 +2321,33 @@ sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/
|
|||
compression_algorithm deflate;
|
||||
}</programlisting>
|
||||
|
||||
<para>For descriptions of each available option, refer to the
|
||||
manual page for <filename>racoon.conf</filename>.</para>
|
||||
<para>For descriptions of each available option, refer to the
|
||||
manual page for <filename>racoon.conf</filename>.</para>
|
||||
|
||||
<para>The Security Policy Database (<acronym>SPD</acronym>)
|
||||
needs to be configured so that &os; and
|
||||
<application>racoon</application> are able to encrypt and
|
||||
decrypt network traffic between the hosts.</para>
|
||||
<para>The Security Policy Database (<acronym>SPD</acronym>)
|
||||
needs to be configured so that &os; and
|
||||
<application>racoon</application> are able to encrypt and
|
||||
decrypt network traffic between the hosts.</para>
|
||||
|
||||
<para>This can be achieved with a shell script, similar to the
|
||||
following, on the corporate gateway. This file will be used
|
||||
during system initialization and should be saved as
|
||||
<filename>/usr/local/etc/racoon/setkey.conf</filename>.</para>
|
||||
<para>This can be achieved with a shell script, similar to the
|
||||
following, on the corporate gateway. This file will be used
|
||||
during system initialization and should be saved as
|
||||
<filename>/usr/local/etc/racoon/setkey.conf</filename>.</para>
|
||||
|
||||
<programlisting>flush;
|
||||
<programlisting>flush;
|
||||
spdflush;
|
||||
# To the home network
|
||||
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
|
||||
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;</programlisting>
|
||||
|
||||
<para>Once in place, <application>racoon</application> may be
|
||||
started on both gateways using the following command:</para>
|
||||
<para>Once in place, <application>racoon</application> may be
|
||||
started on both gateways using the following command:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>/usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log</userinput></screen>
|
||||
|
||||
<para>The output should be similar to the following:</para>
|
||||
<para>The output should be similar to the following:</para>
|
||||
|
||||
<programlisting>corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
|
||||
<programlisting>corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
|
||||
Foreground mode.
|
||||
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
|
||||
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
|
||||
|
|
@ -2352,43 +2360,43 @@ Foreground mode.
|
|||
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
|
||||
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)</programlisting>
|
||||
|
||||
<para>To ensure the tunnel is working properly, switch to
|
||||
another console and use &man.tcpdump.1; to view network
|
||||
traffic using the following command. Replace
|
||||
<literal>em0</literal> with the network interface card as
|
||||
required:</para>
|
||||
<para>To ensure the tunnel is working properly, switch to
|
||||
another console and use &man.tcpdump.1; to view network
|
||||
traffic using the following command. Replace
|
||||
<literal>em0</literal> with the network interface card as
|
||||
required:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>tcpdump -i em0 host <replaceable>172.16.5.4 and dst 192.168.1.12</replaceable></userinput></screen>
|
||||
<screen>&prompt.root; <userinput>tcpdump -i em0 host <replaceable>172.16.5.4 and dst 192.168.1.12</replaceable></userinput></screen>
|
||||
|
||||
<para>Data similar to the following should appear on the
|
||||
console. If not, there is an issue and debugging the
|
||||
returned data will be required.</para>
|
||||
<para>Data similar to the following should appear on the
|
||||
console. If not, there is an issue and debugging the
|
||||
returned data will be required.</para>
|
||||
|
||||
<programlisting>01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
|
||||
<programlisting>01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
|
||||
01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
|
||||
01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)</programlisting>
|
||||
|
||||
<para>At this point, both networks should be available and
|
||||
seem to be part of the same network. Most likely both
|
||||
networks are protected by a firewall. To allow traffic to
|
||||
flow between them, rules need to be added to pass packets.
|
||||
For the &man.ipfw.8; firewall, add the following lines to
|
||||
the firewall configuration file:</para>
|
||||
<para>At this point, both networks should be available and seem
|
||||
to be part of the same network. Most likely both networks are
|
||||
protected by a firewall. To allow traffic to flow between
|
||||
them, rules need to be added to pass packets. For the
|
||||
&man.ipfw.8; firewall, add the following lines to the firewall
|
||||
configuration file:</para>
|
||||
|
||||
<programlisting>ipfw add 00201 allow log esp from any to any
|
||||
<programlisting>ipfw add 00201 allow log esp from any to any
|
||||
ipfw add 00202 allow log ah from any to any
|
||||
ipfw add 00203 allow log ipencap from any to any
|
||||
ipfw add 00204 allow log udp from any 500 to any</programlisting>
|
||||
|
||||
<note>
|
||||
<para>The rule numbers may need to be altered depending on
|
||||
the current host configuration.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>The rule numbers may need to be altered depending on the
|
||||
current host configuration.</para>
|
||||
</note>
|
||||
|
||||
<para>For users of &man.pf.4; or &man.ipf.8;, the following
|
||||
rules should do the trick:</para>
|
||||
<para>For users of &man.pf.4; or &man.ipf.8;, the following
|
||||
rules should do the trick:</para>
|
||||
|
||||
<programlisting>pass in quick proto esp from any to any
|
||||
<programlisting>pass in quick proto esp from any to any
|
||||
pass in quick proto ah from any to any
|
||||
pass in quick proto ipencap from any to any
|
||||
pass in quick proto udp from any port = 500 to any port = 500
|
||||
|
|
@ -2399,11 +2407,11 @@ pass out quick proto ipencap from any to any
|
|||
pass out quick proto udp from any port = 500 to any port = 500
|
||||
pass out quick on gif0 from any to any</programlisting>
|
||||
|
||||
<para>Finally, to allow the machine to start support for the
|
||||
<acronym>VPN</acronym> during system initialization, add the
|
||||
following lines to <filename>/etc/rc.conf</filename>:</para>
|
||||
<para>Finally, to allow the machine to start support for the
|
||||
<acronym>VPN</acronym> during system initialization, add the
|
||||
following lines to <filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>ipsec_enable="YES"
|
||||
<programlisting>ipsec_enable="YES"
|
||||
ipsec_program="/usr/local/sbin/setkey"
|
||||
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
|
||||
racoon_enable="yes"</programlisting>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue