summaryrefslogtreecommitdiff
path: root/share/man/man8/vpn.8
diff options
context:
space:
mode:
Diffstat (limited to 'share/man/man8/vpn.8')
-rw-r--r--share/man/man8/vpn.8734
1 files changed, 0 insertions, 734 deletions
diff --git a/share/man/man8/vpn.8 b/share/man/man8/vpn.8
deleted file mode 100644
index 3ba0852d0e1..00000000000
--- a/share/man/man8/vpn.8
+++ /dev/null
@@ -1,734 +0,0 @@
-.\" $OpenBSD: vpn.8,v 1.109 2006/05/02 21:14:43 jmc Exp $
-.\"
-.\" Copyright 1998 Niels Provos <provos@physnet.uni-hamburg.de>
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\" must display the following acknowledgement:
-.\" This product includes software developed by Niels Provos.
-.\" 4. The name of the author may not be used to endorse or promote products
-.\" derived from this software without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
-.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
-.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-.\"
-.\" Manual page, using -mandoc macros
-.\"
-.Dd February 9, 1999
-.Dt VPN 8
-.Os
-.Sh NAME
-.Nm vpn
-.Nd configuring the system for virtual private networks
-.Sh DESCRIPTION
-A Virtual Private Network (VPN)
-is used to securely connect two or more subnets over the internet.
-For each subnet there is a security gateway which is
-linked via a cryptographically secured tunnel to the security gateway of
-the other subnet.
-.Xr ipsec 4
-is used to provide the necessary network-layer cryptographic services.
-This document describes the configuration process for setting up a VPN.
-.Pp
-Briefly, creating a VPN consists of the following steps:
-.Pp
-.Bl -enum -compact
-.It
-Enable packet forwarding.
-.It
-Choose a key exchange method: manual or automated.
-.It
-For manual keying, generate the keys.
-.It
-For manual keying, create the Security Associations (SA).
-.It
-For manual keying, create the appropriate IPsec flows.
-.It
-For automated keying, configure the keying daemon.
-.It
-Configure firewall rules appropriately.
-.It
-Enable the packet filter.
-.It
-For automated keying, start the keying daemon.
-.It
-Test the setup.
-.El
-.Ss About this page
-It is recommended that a test setup be created before attempting to
-deploy a VPN on the internet.
-The examples in this page can be done using two machines
-directly connected to each other,
-and a little imagination.
-The IP address of each machine represents a gateway address;
-the alias (see below) is simply a hook into a fictitious network.
-.Pp
-The following steps are only necessary
-if the VPN is being set up as a test VPN,
-on an internal LAN.
-.Pp
-The VPN can be represented using two machines (A and B).
-An alias should be added to each machine,
-to give it the appearance of being in another network.
-.Pp
-On machine A:
-.Bd -literal -offset indent
-# ifconfig ne0 192.168.1.13 description "Machine A"
-# ifconfig ne0 alias 10.0.50.1
-.Ed
-.Pp
-On machine B:
-.Bd -literal -offset indent
-# ifconfig bge0 192.168.1.15 description "Machine B"
-# ifconfig bge0 alias 10.0.99.1
-.Ed
-.Pp
-For all other (non-test) cases,
-.Xr ifconfig 8
-should be used to configure machines as normal.
-.Pp
-Additionally, the GATEWAY_* and NETWORK_* variables used in the
-following sections are defined below in
-.Sx Configuring Firewall Rules .
-Please see that section for the correct values for these variables.
-.Ss Enabling Packet Forwarding
-For security gateways, proper operation often requires packet
-forwarding to be enabled using
-.Xr sysctl 8 :
-.Bd -literal -offset indent
-# sysctl net.inet.ip.forwarding=1
-# sysctl net.inet6.ip6.forwarding=1
-.Ed
-.Pp
-Packet forwarding defaults to
-.Sq off .
-.Pp
-Additionally, if
-.Va net.inet.ip.forwarding
-is set to 2,
-IP forwarding is restricted to IPsec traffic only.
-These and other IPsec related options are documented in
-.Xr sysctl 3 .
-.Pp
-For more permanent operation,
-the appropriate option(s) can be enabled in
-.Xr sysctl.conf 5 .
-.Ss Choosing a Key Exchange Method
-There are currently two key exchange methods available:
-.Pp
-.Bl -bullet -compact
-.It
-manual keying:
-.Xr ipsecadm 8
-or
-.Xr ipsecctl 8
-.It
-automated keying:
-.Xr isakmpd 8
-.El
-.Ss Generating Manual Keys [manual keying]
-The shared secret symmetric keys used to create a VPN can
-be any hexadecimal value, so long as both sides of the connection use
-the same values.
-Since the security of the VPN is based on these keys
-being unguessable, it is very important that the keys be chosen using a
-strong random source.
-One practical method of generating them is by using the
-.Xr random 4
-device.
-To produce 160 bits (20 bytes) of randomness, for example, do:
-.Bd -literal -offset indent
-$ openssl rand 20 | hexdump -e '20/1 "%02x"'
-.Ed
-or:
-.Bd -literal -offset indent -compact
-$ openssl rand 20 | perl -pe 's/./unpack("H2",$&)/ges'
-.Ed
-.Pp
-Different cipher types may require different sized keys.
-.Pp
-.Bl -column "CipherXX" "Key Length" -offset indent -compact
-.It Em Cipher Key Length
-.It Li DES Ta "56 bits"
-.It Li 3DES Ta "168 bits"
-.It Li AES Ta "Variable (128 bits recommended)"
-.It Li BLF Ta "Variable (160 bits recommended)"
-.It Li CAST Ta "Variable (128 bits maximum and recommended)"
-.It Li SKIPJACK Ta "80 bits"
-.El
-.Pp
-Use of DES or SKIPJACK as an encryption algorithm is not recommended
-(except for backwards compatibility) due to their short key length.
-Furthermore, recent attacks on SKIPJACK have shown severe weaknesses
-in its structure.
-.Pp
-Note that DES requires 8 bytes to form a 56-bit key and 3DES requires 24 bytes
-to form its 168-bit key.
-This is because the most significant bit of each byte is ignored by both
-algorithms.
-.Pp
-The following would create suitable keys for a 3DES encryption key
-and SHA-1 authentication key:
-.Bd -literal -offset indent
-$ openssl rand 24 | hexdump -e '24/1 "%02x"' \*(Gt enc_key
-$ openssl rand 20 | hexdump -e '20/1 "%02x"' \*(Gt auth_key
-.Ed
-.Pp
-The 3DES encryption key needs 192 bits (3x64), or 24 bytes.
-The SHA-1 authentication key needs 160 bits, or 20 bytes.
-.Ss Creating Security Associations [manual keying]
-Before the IPsec flows can be defined, two Security Associations (SAs)
-must be defined on each end of the VPN e.g.:
-.Bd -literal -offset indent
-# ipsecadm new esp -src $GATEWAY_A -dst $GATEWAY_B \e
- -spi $SPI_AB -forcetunnel -enc 3des -auth sha1 \e
- -keyfile $ENCRYPTION_KEY_FILE \e
- -authkeyfile $AUTHENTICATION_KEY_FILE
-
-# ipsecadm new esp -src $GATEWAY_B -dst $GATEWAY_A \e
- -spi $SPI_BA -forcetunnel -enc 3des -auth sha1 \e
- -keyfile $ENCRYPTION_KEY_FILE \e
- -authkeyfile $AUTHENTICATION_KEY_FILE
-.Ed
-.Pp
-Note that the
-.Fl key
-and
-.Fl authkey
-options may be used to specify the keys directly in the
-.Xr ipsecadm 8
-command line.
-However, another user could view the keys by using the
-.Xr ps 1
-command at the appropriate time (or use a program for doing so).
-.Pp
-Instead of
-.Xr ipsecadm 8 ,
-the
-.Xr ipsecctl 8
-utility can be used to define SAs.
-It uses a rule based syntax similar to
-.Xr pf.conf 5 .
-On gateway A add these lines to the file
-.Xr ipsec.conf 5 :
-.Bd -literal -offset indent
-esp from 192.168.1.13 to 192.168.1.15 spi 0xdeadbeef:0xbeefdead \e
- authkey file "/path/to/gateA.auth:/path/to/gateB.auth" \e
- enckey file "/path/to/gateA.enc:/path/to/gateB.enc"
-.Ed
-.Pp
-Similarly on gateway B add these lines to
-.Xr ipsec.conf 5 :
-.Bd -literal -offset indent
-esp from 192.168.1.15 to 192.168.1.13 spi 0xbeefdead:0xdeadbeef \e
- authkey file "/path/to/gateB.auth:/path/to/gateA.auth" \e
- enckey file "/path/to/gateB.enc:/path/to/gateA.enc"
-.Ed
-.Pp
-Note that when no authentication and encryption algorithms are defined,
-.Xr ipsecctl 8
-will automatically use HMAC-SHA2-256 for authentication and AES-128 in
-countermode for encryption.
-Therefore the authentication key needs to be 256 bits long; the encryption key
-160 bits.
-For details see
-.Xr ipsec.conf 5 .
-.Ss Creating IPsec Flows [manual keying]
-Both IPsec gateways need to configure
-.Xr ipsec 4
-routes (flows) with the
-.Xr ipsecadm 8
-tool.
-Two flows are created on each machine:
-the first is for outbound flows,
-the second is the ingress filter for the incoming security association.
-.Pp
-On the security gateway of subnet A:
-.Bd -literal -offset indent
-# ipsecadm flow -out -require -proto esp \e
- -src $GATEWAY_A -dst $GATEWAY_B \e
- -addr $NETWORK_A $NETWORK_B
-# ipsecadm flow -in -require -proto esp \e
- -src $GATEWAY_A -dst $GATEWAY_B \e
- -addr $NETWORK_B $NETWORK_A
-.Ed
-.Pp
-On the security gateway of subnet B:
-.Bd -literal -offset indent
-# ipsecadm flow -out -require -proto esp \e
- -src $GATEWAY_B -dst $GATEWAY_A \e
- -addr $NETWORK_B $NETWORK_A
-# ipsecadm flow -in -require -proto esp \e
- -src $GATEWAY_B -dst $GATEWAY_A \e
- -addr $NETWORK_A $NETWORK_B
-.Ed
-.Pp
-Again it is possible to use
-.Xr ipsecctl 8
-to define flows.
-On gateway A add this line to
-.Xr ipsec.conf 5 :
-.Bd -literal -offset indent
-flow esp from 10.0.50.0/24 to 10.0.99.0/24 peer 192.168.1.15
-.Ed
-.Pp
-And on gateway B this line:
-.Bd -literal -offset indent
-flow from 10.0.99.0/24 to 10.0.50.0/24 peer 192.168.1.13
-.Ed
-.Pp
-Note that
-.Xr ipsecctl 8
-will automatically use ESP in tunnel mode.
-For details see
-.Xr ipsec.conf 5 .
-.Pp
-To activate the SAs and flows, run this command on both gateways:
-.Bd -literal -offset indent
-# ipsecctl -f /etc/ipsec.conf
-.Ed
-.Ss Configuring the Keying Daemon [automated keying]
-Unless manual keying is used, both security gateways need to use the
-.Xr isakmpd 8
-key management daemon.
-.Xr isakmpd 8
-implements security policy using the
-.Em KeyNote
-trust management system.
-.Pp
-To create a VPN between the same two C class networks as the example
-above, using
-.Xr isakmpd 8 :
-.Bl -enum
-.It
-Create
-.Pa /etc/isakmpd/isakmpd.conf
-for machine A:
-.Bd -literal -offset indent
-# Filter incoming phase 1 negotiations so they are only
-# valid if negotiating with this local address.
-
-[General]
-Listen-On= 192.168.1.13
-
-# Incoming phase 1 negotiations are multiplexed on the
-# source IP address. Phase 1 is used to set up a protected
-# channel just between the two gateway machines.
-# This channel is then used for the phase 2 negotiation
-# traffic (i.e. encrypted & authenticated).
-
-[Phase 1]
-192.168.1.15= peer-machineB
-
-# 'Phase 2' defines which connections the daemon
-# should establish. These connections contain the actual
-# "IPsec VPN" information.
-
-[Phase 2]
-Connections= VPN-A-B
-
-# ISAKMP phase 1 peers (from [Phase 1])
-
-[peer-machineB]
-Phase= 1
-Address= 192.168.1.15
-Configuration= Default-main-mode
-Authentication= yoursharedsecret
-
-# IPSEC phase 2 connections (from [Phase 2])
-
-[VPN-A-B]
-Phase= 2
-ISAKMP-peer= peer-machineB
-Configuration= Default-quick-mode
-Local-ID= machineA-internal-network
-Remote-ID= machineB-internal-network
-
-# ID sections (as used in [VPN-A-B])
-
-[machineA-internal-network]
-ID-type= IPV4_ADDR_SUBNET
-Network= 10.0.50.0
-Netmask= 255.255.255.0
-
-[machineB-internal-network]
-ID-type= IPV4_ADDR_SUBNET
-Network= 10.0.99.0
-Netmask= 255.255.255.0
-
-# Main and Quick Mode descriptions
-# (as used by peers and connections).
-
-[Default-main-mode]
-EXCHANGE_TYPE= ID_PROT
-Transforms= 3DES-SHA,BLF-SHA
-
-[Default-quick-mode]
-EXCHANGE_TYPE= QUICK_MODE
-Suites= QM-ESP-3DES-SHA-SUITE
-.Ed
-.Pp
-.It
-Create
-.Pa /etc/isakmpd/isakmpd.conf
-for machine B:
-.Bd -literal -offset indent
-# Filter incoming phase 1 negotiations so they are only
-# valid if negotiating with this local address.
-
-[General]
-Listen-On= 192.168.1.15
-
-# Incoming phase 1 negotiations are multiplexed on the
-# source IP address. Phase 1 is used to set up a protected
-# channel just between the two gateway machines.
-# This channel is then used for the phase 2 negotiation
-# traffic (i.e. encrypted & authenticated).
-
-[Phase 1]
-192.168.1.13= peer-machineA
-
-# 'Phase 2' defines which connections the daemon
-# should establish. These connections contain the actual
-# "IPsec VPN" information.
-
-[Phase 2]
-Connections= VPN-B-A
-
-# ISAKMP phase 1 peers (from [Phase 1])
-
-[peer-machineA]
-Phase= 1
-Address= 192.168.1.13
-Configuration= Default-main-mode
-Authentication= yoursharedsecret
-
-# IPSEC phase 2 connections (from [Phase 2])
-
-[VPN-B-A]
-Phase= 2
-ISAKMP-peer= peer-machineA
-Configuration= Default-quick-mode
-Local-ID= machineB-internal-network
-Remote-ID= machineA-internal-network
-
-# ID sections (as used in [VPN-A-B])
-
-[machineA-internal-network]
-ID-type= IPV4_ADDR_SUBNET
-Network= 10.0.50.0
-Netmask= 255.255.255.0
-
-[machineB-internal-network]
-ID-type= IPV4_ADDR_SUBNET
-Network= 10.0.99.0
-Netmask= 255.255.255.0
-
-# Main and Quick Mode descriptions
-# (as used by peers and connections).
-
-[Default-main-mode]
-EXCHANGE_TYPE= ID_PROT
-Transforms= 3DES-SHA,BLF-SHA
-
-[Default-quick-mode]
-EXCHANGE_TYPE= QUICK_MODE
-Suites= QM-ESP-3DES-SHA-SUITE
-.Ed
-.It
-Read through the configuration one more time.
-The only real differences between the two files in this example are
-the IP addresses, and ordering of Local-ID and Remote-ID for the VPN
-itself.
-Note that the shared secret (the
-.Em Authentication
-tag) must match between machineA and machineB.
-.Pp
-Due to the sensitive information contained in the configuration file,
-it must be owned by root and installed without any permissions for
-"group" or "other".
-.Pp
-.Dl # chown root:wheel /etc/isakmpd/isakmpd.conf
-.Dl # chmod 0600 /etc/isakmpd/isakmpd.conf
-.It
-Create a simple
-.Pa /etc/isakmpd/isakmpd.policy
-file for both machine A and machine B (identical):
-.Bd -literal -offset indent
-Keynote-version: 2
-Authorizer: "POLICY"
-Conditions: app_domain == "IPsec policy" &&
- esp_present == "yes" &&
- esp_enc_alg != "null" -\*(Gt "true";
-.Ed
-.Pp
-Due to the sensitive information contained in the policy file,
-it must be owned by root and installed without any permissions for
-"group" or "other".
-.Pp
-.Dl # chown root:wheel /etc/isakmpd/isakmpd.policy
-.Dl # chmod 0600 /etc/isakmpd/isakmpd.policy
-.El
-.Ss Configuring Firewall Rules
-.Xr pf 4
-needs to be configured such that all packets from the outside are blocked
-by default.
-Only successfully IPsec-processed packets (those on the
-.Xr enc 4
-interface) or key management packets
-(for automated keying,
-UDP packets with source and destination ports of 500)
-should be allowed to pass.
-.Pp
-Additional filter rules may be present for other traffic,
-though care should be taken that other rules do not leak IPsec traffic.
-NAT rules can also be used on the
-.Xr enc 4
-interface.
-.Pp
-.Sy Note :
-The examples in this page describe a test setup on an internal LAN,
-using private (non-routable) IP addresses.
-In a typical setup,
-at least GATEWAY_A and GATEWAY_B would be configured using
-public (routable) IP addresses.
-NETWORK_A and NETWORK_B may or may not use public IP addresses,
-depending on the network.
-.Pp
-The
-.Xr pf.conf 5
-rules for a tunnel which uses encryption (the ESP IPsec protocol) and
-.Xr isakmpd 8
-on security gateway A might look like this:
-.Bd -literal -offset indent
-GATEWAY_A = "192.168.1.13"
-GATEWAY_B = "192.168.1.15"
-NETWORK_A = "10.0.50.0/24"
-NETWORK_B = "10.0.99.0/24"
-
-ext_if="ne0"
-
-# default deny
-# $ext_if is the only interface going to the outside.
-block log on { enc0, $ext_if } all
-
-# Pass encrypted traffic to/from security gateways
-pass in proto esp from $GATEWAY_B to $GATEWAY_A
-pass out proto esp from $GATEWAY_A to $GATEWAY_B
-
-# Need to allow ipencap traffic on enc0.
-pass in on enc0 proto ipencap from $GATEWAY_B to $GATEWAY_A
-
-# Pass traffic to/from the designated subnets.
-pass in on enc0 from $NETWORK_B to $NETWORK_A
-pass out on enc0 from $NETWORK_A to $NETWORK_B
-
-# Pass isakmpd(8) traffic to/from the security gateways
-pass in on $ext_if proto udp from $GATEWAY_B port = 500 \e
- to $GATEWAY_A port = 500
-pass out on $ext_if proto udp from $GATEWAY_A port = 500 \e
- to $GATEWAY_B port = 500
-.Ed
-.Pp
-The
-.Xr pf.conf 5
-rules on security gateway B might look like this:
-.Bd -literal -offset indent
-GATEWAY_A = "192.168.1.13"
-GATEWAY_B = "192.168.1.15"
-NETWORK_A = "10.0.50.0/24"
-NETWORK_B = "10.0.99.0/24"
-
-ext_if="bge0"
-
-# default deny
-# $ext_if is the only interface going to the outside.
-block log on { enc0, $ext_if } all
-
-# Passing in encrypted traffic from security gateways
-pass in proto esp from $GATEWAY_A to $GATEWAY_B
-pass out proto esp from $GATEWAY_B to $GATEWAY_A
-
-# Need to allow ipencap traffic on enc0.
-pass in on enc0 proto ipencap from $GATEWAY_A to $GATEWAY_B
-
-# Passing in traffic from the designated subnets.
-pass in on enc0 from $NETWORK_A to $NETWORK_B
-pass out on enc0 from $NETWORK_B to $NETWORK_A
-
-# Passing in isakmpd(8) traffic from the security gateways
-pass in on $ext_if proto udp from $GATEWAY_A port = 500 \e
- to $GATEWAY_B port = 500
-pass out on $ext_if proto udp from $GATEWAY_B port = 500 \e
- to $GATEWAY_A port = 500
-.Ed
-.Ss Enabling the Packet Filter
-Enable the packet filter and load the ruleset:
-.Bd -literal -offset indent
-# pfctl -e
-# pfctl -f /etc/pf.conf
-.Ed
-.Ss Starting the Keying Daemon [automated keying]
-Start
-.Xr isakmpd 8
-.Pp
-On both machines, run:
-.Pp
-.Dl # /sbin/isakmpd
-.Pp
-To run with verbose debugging enabled, instead start with:
-.Pp
-.Dl # /sbin/isakmpd -d -DA=99
-.Ss Testing the Setup
-It is important to check the setup is working correctly.
-Remember that the following examples illustrate a test setup only,
-and therefore tests carried out on GATEWAY_A and NETWORK_A will be
-carried out on the same machine (Machine A).
-If this were a real setup, GATEWAY_A and a machine on NETWORK_A would be
-different machines.
-.Pp
-Using the test setup,
-first check the routing table shows the routes between the two gateways.
-.Pp
-On GATEWAY_A:
-.Bd -literal -offset 1n
-$ netstat -rn -f encap
-Routing tables
-
-Encap:
-Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
-10.0.99/24 0 10.0.50/24 0 0 192.168.1.15/50/use/in
-10.0.50/24 0 10.0.99/24 0 0 192.168.1.15/50/require/out
-.Ed
-.Pp
-This shows that anything with source address 10.0.99.0/24 (NETWORK_B)
-is routed to destination 10.0.50.0/24 (NETWORK_A),
-and vice versa.
-The opposite would be true if
-.Xr netstat 1
-were run on GATEWAY_B.
-.Pp
-Note that the routing table above is given for an automated keying session.
-SA information for a manual keying session would differ slightly: the
-.Dq Type
-field would be
-.Dq require
-for both directions.
-.Pp
-Next check that you can
-.Xr ping 8
-the networks:
-.Pp
-On NETWORK_A:
-.Pp
-.Dl $ ping -I 10.0.50.1 10.0.99.1
-.Pp
-Note the
-.Fl I
-option passed to
-.Xr ping 8 :
-this is necessary to specify a source address
-from the network.
-Check that the
-.Xr ping 8
-works from both NETWORK_A and NETWORK_B, changing the arguments as necessary.
-.Pp
-Check that the traffic between the two networks really is
-ESP encapsulated.
-On GATEWAY_A:
-.Pp
-.Dl # tcpdump -n -i ne0 esp
-.Pp
-On NETWORK_A:
-.Pp
-.Dl $ ping -I 10.0.50.1 10.0.99.1
-.Pp
-Check that
-.Xr tcpdump 8
-shows ESP packets whilst the ping is in progress.
-That shows that the traffic is IPsec encapsulated.
-.Pp
-If both networks are pingable,
-the routing tables look as described above,
-and
-.Xr tcpdump 8
-is working as described,
-it means the VPN is working correctly.
-However, it is also important to check that no IPsec traffic
-is being leaked,
-either by badly designed firewall rules
-or by a misconfigured VPN setup.
-.Pp
-On GATEWAY_A:
-.Pp
-.Dl "# tcpdump -n -i ne0 not esp and host 192.168.1.15"
-.Pp
-On NETWORK_A:
-.Pp
-.Dl $ ping -I 10.0.50.1 10.0.99.1
-.Pp
-This time
-.Xr tcpdump 8
-has been instructed to ignore ESP packets going to
-host 192.168.1.15 (GATEWAY_B),
-and no traffic should be seen whilst the ping is running.
-One exception to this is if the automated keying setup has been followed,
-in which case
-.Xr isakmpd 8
-key management packets on UDP port 500 may be seen.
-This is perfectly normal.
-If any traffic is being leaked
-i.e. the last ping detailed above is showing traffic,
-it is suggested that the administrator review the steps above,
-paying particular notice to the firewall configuration procedures.
-.Sh FILES
-.Bl -tag -width "/etc/isakmpd/isakmpd.policyXX" -compact
-.It Pa /etc/ipsec.conf
-.Xr ipsecctl 8
-configuration file.
-.It Pa /etc/isakmpd/isakmpd.conf
-.Xr isakmpd 8
-configuration file.
-.It Pa /etc/isakmpd/isakmpd.policy
-.Xr isakmpd 8
-policy file.
-.It Pa /etc/pf.conf
-Firewall configuration file.
-.It Pa /usr/share/ipsec/rc.vpn
-Sample VPN configuration file.
-.El
-.Sh SEE ALSO
-.Xr netstat 1 ,
-.Xr openssl 1 ,
-.Xr sysctl 3 ,
-.Xr enc 4 ,
-.Xr ipsec 4 ,
-.Xr keynote 4 ,
-.Xr ipsec.conf 5 ,
-.Xr isakmpd.conf 5 ,
-.Xr isakmpd.policy 5 ,
-.Xr pf.conf 5 ,
-.Xr ifconfig 8 ,
-.Xr ipsecadm 8 ,
-.Xr ipsecctl 8 ,
-.Xr isakmpd 8 ,
-.Xr pfctl 8 ,
-.Xr ping 8 ,
-.Xr sysctl 8 ,
-.Xr tcpdump 8
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-22 05:37:56 +0000