Date: Sat, 06 Apr 2002 17:49:54 -0500 From: Mike DeGraw-Bertsch <mbertsch@radioactivedata.org> To: Nik Clayton <nik@freebsd.org> Cc: freebsd-doc@freebsd.org Subject: Re: docs/36723: IPSec section is unintelligible Message-ID: <3CAF7B92.3060100@radioactivedata.org> References: <200204061610.g36GA3i07554@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nik,
Excellent article. My only concerns are that it doesn't cover X.509
certs, and only applies to VPNs. I'll agree that VPNs are probably the
most common use for IPsec, but transport mode is still important and useful.
The piece I was working on for th the handbook is more of a quick
introduction to IPsec, followed by a guide to configuring racoon, and
using transport and tunnel mode.
I don't know which would be more useful to folks. Just wanted to share
my thoughts.
-Mike
Nik Clayton wrote:
> The following reply was made to PR docs/36723; it has been noted by GNATS.
>
> From: Nik Clayton <nik@freebsd.org>
> To: Murray Stokely <murray@FreeBSD.org>
> Cc: FreeBSD-gnats-submit@FreeBSD.org
> Subject: Re: docs/36723: IPSec section is unintelligible
> Date: Sat, 6 Apr 2002 17:05:41 +0100
>
> --L0TNCHh3fkwjpuuE
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Apr 03, 2002 at 10:09:11PM -0800, Murray Stokely wrote:
> > People often complain about the IPSec section in the FreeBSD Handbook.
> > The material is in great need of clarification.
>
> Anyone feel like SGML'ifying this (and fleshing it out as necessary)?
> It's been kicking around my hard disk for ages, and I never found the
> need to finish it up. . .
>
> N
>
> /*-
> * Copyright (c) 2001 Nik Clayton
> * All rights reserved.
> *
> * Redistribution is not permitted. If you are reading this it's because t=
> his
> * is an early version of this article that I have put out for review. It =
> is
> * not finished, and I do not want copies that possibly provide incorrect
> * information floating around the net.
> *
> * THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' =
> AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO=
> SE
> * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI=
> AL
> * 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, STRI=
> CT
> * 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
> */
>
> ToDo:
>
> Check the path of the racoon config file
>
> Talk about the racoon settings that talk about timeouts
>
> Talk about choosing a good value for "secret" in psk.txt
>
> Check that racoon without a policy still sets up security associations
>
> Get sample tcpdump output between encrypted networks
>
> Show how to configure Windows hosts with a WINS Server
>
> Show dhcpd.conf netbios config option.
>
> Creating a VPN between two networks, separated by the Internet, using FreeB=
> SD
> gateways.
>
> The Problem
>
> There's no standard for what constitutes a VPN. VPNs can be implemented
> using a number of different technologies, each of which have their own
> strengths and weaknesses. This article presents a number of scenarios,
> and strategies for implementing a VPN for each scenario.
>
> Scenario #1: Two networks, connected to the Internet, to behave as one
>
> This is the scenario that caused me to first investigating VPNs. The
> premise is as follows:
>
> * You have at least two sites
>
> * Both sites are using IP internally
>
> * Both sites are connected to the Internet, through a gateway that is
> running FreeBSD.
>
> * The gateway on each network has at least one public IP address.
>
> * The internal addresses of the two networks can be public or private
> IP addresses, it doesn't matter. You can be running NAT on the
> gateway machine if necessary.
>
> * The internal IP addresses of the two networks DO NOT COLLIDE. Whi=
> le
> I expect it is theoretically possible to use a combination of VPN
> technology and NAT to get this to work, I expect it to be a
> configuration nightmare.
>
> If you find that you are trying to connect two networks, both of
> which, internally, use the same private IP address range (e.g., both
> of them use 192.168.1.x), then one of the networks will have to be
> renumbered.
>
> I think it's now a law that every VPN article must feature some ASCII
> artwork. This one is no exception.
>
> The network topology might look something like this:
>
>
> Network #1 [ Internal Hosts ] Private Net, 192.168.1.2-2=
> 54
> [ Win9x/NT/2K ]
> [ Unix ]
> |
> |
> .---[fxp1]---. Private IP, 192.168.1.1
> | FreeBSD |
> `---[fxp0]---' Public IP, A.B.C.D
> |
> |
> -=3D-=3D- Internet -=3D-=3D-
> |
> |
> .---[fxp0]---. Public IP, W.X.Y.Z
> | FreeBSD |
> `---[fxp1]---' Private IP, 192.168.2.1
> |
> |
> Network #2 [ Internal Hosts ]
> [ Win9x/NT/2K ] Private Net, 192.168.2.2-2=
> 54
> [ Unix ]
>
>
> Notice the two public IP addresses. I'll use the letters to refer to t=
> hem
> in the rest of this article. Anywhere you see those letters in this
> article, replace them with your own public IP addresses. Note also that
> that internally, the two gateway machines have .1 IP addresses, and that
> the two networks have different private IP address (192.168.1.x and
> 192.168.2.x respectively). All the machines on the private networks ha=
> ve
> been configured to use the .1 machine as their default gateway.
>
> The intention is that, from a network point of view, each network should
> view the machines on the other network as though they were directly
> attached the same router -- albeit a slightly slow router with an
> occasional tendency to drop packets.
>
> This means that (for example), machine 192.168.1.20 should be able to r=
> un
>
> ping 192.168.2.34
>
> and have it work, transparently. Windows machines should be able to see
> the machines on the other network, browse file shares, and so on, in
> exactly the same way that they can browse machines on the local network.
>
> And the whole thing has to be secure. This means that traffic between =
> the
> two networks has to be encrypted.
>
> Creating a VPN between these two networks is a multi-step process. The
> stages are as follows;
>
> 1. Create a "virtual" network link between the two networks, across
> the Internet. Test it, using tools like ping(8), to make sure it
> works.
>
> 2. Apply security policies to ensure that traffic between the two
> networks is transparently encrypted and decrypted as necessary.
> Test this, using toolks like tcpdump(8), to ensure that traffic is
> encrypted.
>
> 3. Configure additional software on the FreeBSD gateways, to allow
> Windows machines to see one another across the VPN.
>
> Step 1: Creating and testing a "virtual" network link
>
> Suppose that you were logged in to the gateway machine on network #1 (w=
> ith
> public IP address A.B.C.D, private IP address 192.168.1.1), and you ran
> "ping 192.168.2.1", which is the private address of the machine with IP
> address W.X.Y.Z. What needs to happen in order for this to work?
> =20
> 1. The gateway machine needs to know how to reach 192.168.2.1. In
> other words, it needs to have a route to 192.168.2.1.
>
> 2. Private IP addresses, such as those in the 192.168.x range are not
> supposed to appear on the Internet at large. Instead, each packet
> you send to 192.168.2.1 will need to be wrapped up inside another
> packet. This packet will need to appear to be from A.B.C.D, and =
> it
> will have to be sent to W.X.Y.Z. This process is called
> "encapsulation".
>
> 3. Once this packet arrives at W.X.Y.Z it will need to
> "unencapsulated", and delivered to 192.168.2.1.
>
> You can think of this as requiring a "tunnel" between the two networks.
> The two "tunnel mouths" are the IP addresses A.B.C.D and W.X.Y.Z, and t=
> he
> tunnel must be told the addresses of the private IP addresses that will=
> be
> allowed to pass through it. The tunnel is used to transfer traffic with
> private IP addresses across the public Internet.
>
> This tunnel is created by using the generic interface, or "gif" devices=
> on
> FreeBSD. As you can imagine, the gif interface on each gateway host mu=
> st
> be configured with four IP addresses; two for the public IP addresses, =
> and
> two for the private IP addresses.
>
> Support for the gif device must be compiled in to the FreeBSD kernel on
> both machines. You can do this by adding the line
>
> pseudo-device gif
>
> to the kernel configuration files on both machines, and then compile,
> install, and reboot as normal.
>
> Configuring the tunnel is a two step process. First the tunnel must be
> told what the outside (or public) IP addresses are, using gifconfig(8).
> Then the private IP addresses must be configured using ifconfig(8).
>
> On the gateway machine on network #1 you would run the following two
> commands to configure the tunnel.
>
> gifconfig gif0 A.B.C.D W.X.Y.Z
> ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
>
> On the other gateway machine you run the same commands, but with the or=
> der
> of the IP addresses reversed.
>
> gifconfig gif0 W.X.Y.Z A.B.C.D
> ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
>
> You can then run=20
>
> gifconfig gif0
>
> to see the configuration. For example, on the network #1 gateway, you
> would see this
>
> # gifconfig gif0
> gif0: flags=3D8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
> inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
> physical address inet A.B.C.D --> W.X.Y.Z
>
> As you can see, a tunnel has been created between the physical addresses
> A.B.C.D and W.X.Y.Z, and the traffic allowed through the tunnel is that
> between 192.168.1.1 and 192.168.2.1.
>
> This will also have added an entry to the routing table on both machine=
> s,
> which you can examine with "netstat -rn". This output is from the gate=
> way
> host on network #1.
>
> # netstat -rn
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Netif Expire
> ...
> 192.168.2.1 192.168.1.1 UH 0 0 gif0
> ...
>
> As the "Flags" value indicates, this is a host route, which means that
> each gateway knows how to reach the other gateway, but they do not know
> how to reach the rest of their respective networks. That problem will =
> be
> fixed shortly.
>
> It is likely that you are running a firewall on both machines. This wi=
> ll
> need to be circumvented for your VPN traffic. You might want to allow =
> all
> traffic between both networks, or you might want to include firewall ru=
> les
> that protect both ends of the VPN from one another.
>
> It greatly simplifies testing if you configure the firewall to allow all
> traffic through the VPN. You can always tighten things up later. If y=
> ou
> are using ipfw(8) on the gateway machines then a command like
>
> ipfw add 1 allow ip from any to any via gif0
>
> will allow all traffic between the two end points of the VPN, without
> affecting your other firewall rules. Obviously you will need to run th=
> is
> command on both gateway hosts.
>
> This is sufficient to allow each gateway machine to ping the other. On
> 192.168.1.1 you should be able to run
>
> ping 192.168.2.1
>
> and get a response, and you should be able to do the same thing on the
> other gateway machine.
>
> However, you will not be able to reach internal machines on either netw=
> ork
> yet. This is because of the routing -- although the gateway machines k=
> now
> how to reach one another, they do not know how to reach the network beh=
> ind
> each one.
>
> To solve this problem you must add a static route on each gateway
> machine. The command to do this on the first gateway would be:
>
> route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
>
> This says "In order to reach the hosts on the network 192.168.2.0, send
> the packets to the host 192.168.2.1". You will need to run a similar
> command on the other gateway, but with the 192.168.1.x addresses instea=
> d.
>
> IP traffic from hosts on one network will now be able to reach hosts on
> the other network.=20
>
> That has now created two thirds of a VPN between the two networks, in as
> much as it's "virtual" and it's a "network". It's not private yet. You
> can test this using ping(8) and tcpdump(8). Log in to the gateway host
> and run
>
> tcpdump dst host 192.168.2.1
>
> In another log in session on the same host run
>
> ping 192.168.2.1
>
> You will see output that looks something like this.
>
> 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
> 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
> 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
> 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
> 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
> 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply
>
> As you can see, the ICMP messages are going back and forth unencrypted.
> If you had used the "-s" parameter to tcpdump(8) to grab more bytes of
> data from the packets you would see more information.
>
> Obviously this is unacceptable. The next section will discuss securing
> the link between the two networks so that it all traffic is automatical=
> ly
> encrypted.
>
> Summary:
>
> * Configure both kernels with "pseudo-device gif"
>
> * Edit /etc/rc.conf on gateway host #1 and add the following lines=20
> (replacing IP addresses as necessary).
>
> gifconfig_gif0=3D"A.B.C.D W.X.Y.Z"
> ifconfig_gif0=3D"inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
> static_routes=3D"vpn"
> route_vpn=3D"192.168.2.0 192.168.2.1 netmask 0xffffff00"
>
> * Edit your firewall script (/etc/rc.firewall, or similar) on both
> hosts, and add
> =20
> ipfw add 1 allow ip from any to any via gif0
>
> * Make similar changes to /etc/rc.conf on gateway host #2, reversing =
> the
> order of IP addresses.
>
> Step 2: Securing the link
>
> To secure the link we will be using IPSec. IPSec provides a mechanism =
> for
> two hosts to agree on an encryption key, and to then use this key in or=
> der
> to encrypt data between the two hosts.
>
> The are two areas of configuration to be considered here.
>
> 1. There must be a mechanism for two hosts to agree on the encryption
> mechanism to use. Once two hosts have agreed on this mechanism
> there is said to be a "security association" between them.
>
> 2. There must be a mechanism for specifying which traffic should be
> encrypted. Obviously, you don't want to encrypt all your outgoing
> traffic -- you only want to encrypt the traffic that is part of the
> VPN. The rules that you put in place to determine what traffic will
> be encrypted are called "security policies".
>
> Security associations and security policies are both maintained by the
> kernel, and can be modified by userland programs. However, before you =
> can
> do this you must configure the kernel to support IPSec and the
> Encapsulated Security Payload (ESP) protocol. This is done by configur=
> ing
> a kernel with
>
> options IPSEC
> options IPSEC_ESP
>
> and recompiling, reinstalling, and rebooting. As before you will need =
> to
> do this to the kernels on both of the gateway hosts.
>
> 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, and so forth, or you can use
> daemons that implement the Internet Key Exchange protocol (IKE) to do t=
> his
> for you.
>
> I recommend the latter. Apart from anything else, it's easier to set u=
> p.
>
> Editing and displaying security policies is carred out using setkey(8).
> By analogy, setkey(8) is to the kernel's security policy tables as
> route(8) is to the kernel's routing tables. setkey(8) can also display
> the current security associations, and to continue the analogy further,=
> is
> akin to "netstat -r" in that respect.
>
> There are a number of choices for daemons to manage security associatio=
> ns
> with FreeBSD. This article will describe how to use one of these, raco=
> on.
> racoon is in the FreeBSD ports collection, in the security/ category, a=
> nd
> is installed in the usual way.
>
> 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 gateways).
>
> The two daemons then contact one another, confirm that they are who they
> say they are (by using the secret key that you configured). The daemons
> then generate a new secret key, and use this to encrypt the traffic over
> the VPN. They periodically change this secret, so that even if an
> attacker were to crack one of the keys (which is as theoretically close=
> to
> unfeasible as it gets) it won't do them much good -- by the time they've
> cracked the key the two daemons have chosen another one.
>
> racoon's configuration is stored in ${PREFIX}/etc/racoon. You should f=
> ind
> a configuration file there, which should not need to be changed too muc=
> h.
> The other component of racoon's configuration, which you will need to
> change, is the 'pre-shared key'.
>
> The default racoon configuration expects to find this in the file
> ${PREFIX}/etc/racoon/psk.txt. It is important to note that the pre-sha=
> red
> key is *not* the key that will be used to encrypt your traffic across t=
> he
> VPN link, it is simply a token that allows the key management daemons to
> trust one another.
> =20
> psk.txt contains a line for each remote site you are dealing with. In
> this example, where there are two sites, each psk.txt file will contain
> one line (because each end of the VPN is only dealing with one other en=
> d).
>
> On gateway host #1 this line should look like this:
>
> W.X.Y.Z secret
>
> That is, the *public* IP address of the remote end, whitespace, and a t=
> ext
> string that provides the secret. Obviously, you shouldn't use "secret"=
> as
> your key -- the normal rules for choosing a password apply.
>
> On gateway host #2 the line would look like this
>
> A.B.C.D secret
>
> That is, the public IP address of the remote end, and the same secret k=
> ey.
> psk.txt must be mode 0600 (i.e., only read/write to root) before racoon
> will run.
>
> You must run racoon on both gateway machines. You will also need to add
> some firewall rules to allow the IKE traffic, which is carried over UDP=
> to
> the isakmp (kmp =3D=3D key management protocol) port. Again, this shou=
> ld be
> fairly early in your firewall ruleset.
>
> ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
> ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
>
> Once racoon is running you can try pinging one gateway host from the
> other. The connection is still not encrypted, but racoon will then set=
> up
> the security associations between the two hosts -- this might take a
> moment, and you may see this as a short delay before the ping commands
> start responding.
>
> Once the security association has been set up you can view it using
> setkey(8). Run
>
> setkey -D
>
> on either host to view the security assocation information.
>
> That's one half of the problem. They other half is setting your securi=
> ty
> policies. =20
>
> To create a sensible security policy, let's review what's been set up so
> far. This discussions hold for both ends of the link.
>
> Each IP packet that you send out has a header that contains data about =
> the
> packet. The header includes the IP addresses of both the source and
> destination. As we already know, private IP addresses, such as the
> 192.168.x.y range are not supposed to appear on the public Internet.
> Instead, they must first be encapsulated inside another packet. This
> packet must have the public source and destination IP addresses
> substituted for the private addresses.
>
> So if your outgoing packet started looking like this:
>
> .----------------------.
> | Src: 192.168.1.1 |
> | Dst: 192.168.2.1 |
> | <other header info> |
> +----------------------+
> | <packet data> |
> `----------------------'
>
> Then it will be encapsulated inside another packet, looking something l=
> ike
> this:
>
> .--------------------------.
> | Src: A.B.C.D |
> | Dst: W.X.Y.Z |
> | <other header info> |
> +--------------------------+
> | .----------------------. |
> | | Src: 192.168.1.1 | |
> | | Dst: 192.168.2.1 | |
> | | <other header info> | |
> | +----------------------+ |
> | | <packet data> | |
> | `----------------------' |
> `--------------------------'
>
> This encapsulation is carried out by the gif device. As you can see, t=
> he
> packet now has real IP addresses on the outside, and our original packet
> has been wrapped up as data inside the packet that will be put out on t=
> he
> Internet.
>
> Obviously, we want all traffic between the VPNs to be encrypted. You
> might try putting this in to words, as=20
>
> If a packet leaves from A.B.C.D, and it is destined for W.X.Y.Z, then
> encrypt it, using the necessary security associations.
>
> If a packet arrives from W.X.Y.Z, and it is destined for A.B.C.D, then
> decrypt it, using the necessary security associations.
>
> That's close, but not quite right. If you did this, all traffic to
> and from W.X.Y.Z, even traffic that was not part of the VPN, would be
> encrypted. That's not quite what you want. The correct policy is as
> follows
>
> If a packet leaves from A.B.C.D, and that packet is encapsulating
> another packet, and it is destined for W.X.Y.Z, then encrypt it, using
> the necessary security associations.
>
> If a packet arrives from W.X.Y.Z, and that packet is encapsulating
> another packet, and it is destined for A.B.C.D, then encrypt it, using
> the necessary security associations.
>
> A subtle change, but a necessary one.
>
> Security policies are also set using setkey(8).
>
> Unfortunately, setkey(8), and the related code, is under almost constant
> development. And the version of setkey(8) included in FreeBSD 4.3 does=
> n't
> quite handle this properly.
>
> If you're using a version of FreeBSD-stable built after 3rd July 2001
> (that includes FreeBSD 4.4 and later) then you have the necessary fixes.
> If you are using an earlier version, including FreeBSD 4.3 and below th=
> en
> you need to make a very small change to the setkey(8) source code, and
> then recompile it and reinstall it.
>
> Without this change, setkey(8) won't allow you to specify the rule to
> correctly match encapsulated packets.
>
> The change is very simple.
>
> 1. Acquire a copy of the FreeBSD source code for the version of
> FreeBSD you are running.
>
> 2. Change to the src/usr.sbin/setkey/ directory.
>
> 3. Edit the file token.l. Find the four lines that look like this:
>
> icmp { PREPROC; yylval.num =3D IPPROTO_ICMP; return(UP_PROTO=
> ); }
> icmp6 { PREPROC; yylval.num =3D IPPROTO_ICMPV6; return(UP_PRO=
> TO); }
> tcp { PREPROC; yylval.num =3D IPPROTO_TCP; return(UP_PROTO)=
> ; }
> udp { PREPROC; yylval.num =3D IPPROTO_UDP; return(UP_PROTO)=
> ; }
>
> and add this line
>
> ipencap { PREPROC; yylval.num =3D IPPROTO_IPV4; return(UP_PROTO=
> ); }
>
> after them.
>
> 4. Rebuild and reinstall setkey(8) by running "make install".
>
> Once you have done this you can configure the security policy. setkey(=
> 8)
> features a configuration language for defining the policy. You can eit=
> her
> enter configuration instructions via stdin, or you can use the -f option
> to specify a filename that contains configuration instructions. =20
>
> The configuration on gateway host #1 (which has the public IP address
> A.B.C.D) to force all outbound traffic to W.X.Y.Z to be encrypted is
>
> spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
> esp/tunnel/A.B.C.D-W.X.Y.Z/require;
>
> Put these commands in a file (e.g., /etc/ipsec.conf) and then run=20
>
> setkey -f /etc/ipsec.conf
>
> "spdadd" tells setkey(8) that we want to add a rule to the secure policy
> database. The rest of this line specifies which packets will match this
> policy. "A.B.C.D/32" and "W.X.Y.Z/32" are the IP addresses and netmasks
> that identify the network or hosts that this policy will apply to. In
> this case, we want it to apply to traffic between these two hosts.
> "ipencap" tells the kernel that this policy should only apply to packets
> that encapsulate other packets. "-P out" says that this policy applies=
> to
> outgoing packets, and "ipsec" says that the packet will be secured.
>
> The second line specifies how this packet will be encrypted. "esp" is =
> the
> protocol that will be used, while "tunnel" indicates that the packet wi=
> ll
> be further encapsulated in an IPSec packet. The repeated use of A.B.C.D
> and W.X.Y.Z is used to select the security association to use, and the
> final "require" mandates that packets must be encrypted if they match t=
> his
> rule.
>
> This rule only matches outgoing packets. You will need a similar rule =
> to
> match incoming packets.
>
> spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
> esp/tunnel/W.X.Y.Z-A.B.C.D/require;
>
> Note the "in" instead of "out" in this case, and the necessary reversal=
> of
> the IP addresses.
>
> The other gateway host (which has the public IP address W.X.Y.Z) will n=
> eed
> similar rules.
>
> spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
> esp/tunnel/W.X.Y.Z-A.B.C.D/require;
> spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
> esp/tunnel/A.B.C.D-W.X.Y.Z/require;
>
> Finally, you need to add firewall rules to allow ESP and IPENCAP packets
> back and forth. These rules will need to be added to both hosts.
>
> ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
> ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
> ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
> ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
>
> Because the rules are symmetric you can use the same rules on each gate=
> way
> host.
>
> Outgoing packets will now look something like this.
>
> .------------------------------. --------------------------.
> | Src: A.B.C.D | |
> | Dst: W.X.Y.Z | |
> | <other header info> | | Encrypt=
> ed
> +------------------------------+ | packet.
> | .--------------------------. | -------------. | contents
> | | Src: A.B.C.D | | | | are=20
> | | Dst: W.X.Y.Z | | | | complet=
> ely
> | | <other header info> | | | |- secure
> | +--------------------------+ | | Encap'd | from th=
> ird
> | | .----------------------. | | -. | packet | party
> | | | Src: 192.168.1.1 | | | | Original |- with real | snooping
> | | | Dst: 192.168.2.1 | | | | packet, | IP addr |
> | | | <other header info> | | | |- private | |
> | | +----------------------+ | | | IP addr | |
> | | | <packet data> | | | | | |
> | | `----------------------' | | -' | |
> | `--------------------------' | -------------' |
> `------------------------------' --------------------------'
>
> When they are received by the far end of the VPN they will first be
> decrypted (using the security associations that have been negotiated by
> racoon). Then they will enter the gif interface, which will unwrap the
> second layer, until you are left with the innermost packet, which can t=
> hen
> travel in to the inner network.
>
> You can check the security using the same ping(8) test from earlier.
> First, log in to the A.B.C.D gateway machine, and run
>
> tcpdump dst host 192.168.2.1
>
> In another log in session on the same host run
>
> ping 192.168.2.1
>
> This time you should see output like the following:
>
> <XXX tcpdump output>
>
> Now, as you can see, tcpdump(8) shows the ESP packets. If you try and
> examine them with the -s option you will see (apparently) gibberish,
> because of the encryption.
>
> Congratulations. You have just set up a VPN between two remote sites.
>
> Summary:
>
> * Configure both kernels with=20
>
> options IPSEC
> options IPSEC_ESP
>
> * Install ports/security/racoon. Edit ${PREFIX}/etc/racoon/psk.txt on
> both gateway hosts, adding an entry for the remote host's IP address
> and a secret key that they both know. Make sure this file is mode
> 0600.
>
> * If necessary, make the one line change to src/usr.sbin/setkey/token=
> .l,
> then recompile and reinstall setkey(8).
>
> * Add the following lines to /etc/rc.conf on each host
>
> ipsec_enable=3D"YES"
> ipsec_file=3D"/etc/ipsec.conf"
>
> * Create an /etc/ipsec.conf on each host that contains the necessary
> spdadd lines. On gateway host #1 this would be
>
> spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
> esp/tunnel/A.B.C.D-W.X.Y.Z/require;
> spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
> esp/tunnel/W.X.Y.Z-A.B.C.D/require;
>
> On gateway host #2 this would be
>
> spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
> esp/tunnel/W.X.Y.Z-A.B.C.D/require;
> spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
> esp/tunnel/A.B.C.D-W.X.Y.Z/require;
>
> * Add firewall rules to allow IKE, ESP, and IPENCAP traffic to both
> hosts
>
> ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
> ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
> ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
> ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
> ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
> ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
>
> Step 3: All the horrible Windows related configuration you need to do
>
> The previous two steps should suffice to get the VPN up and running.
> Machines on each network will be able to refer to one another using IP
> addresses, and all traffic across the link will be automatically and
> securely encrypted.
>
> So far so good. However, you probably have hosts running various flavo=
> urs
> of Windows at each site, and you would like to have them all appear in =
> the
> "Network Neighbourhood" or equivalent.
>
> Out of the box, this won't work. This is because the SMB protocol, aro=
> und
> which Windows' file sharing and related activities are based, was not
> originally designed for use on more than one subnet (or, indeed, for IP
> networks). Over time a number of kludges have been bolted on to the
> protocol to correct for these deficiencies, and you will need to implem=
> ent
> them before browsing will work.
>
> You should note that you don't need FreeBSD machines to do most of what
> follows. I think Windows NT or Windows 2000 hosts acting as domain
> controllers will also do the right thing. Of course, if you don't have
> any NT or 2000 hosts, and you don't feel like paying for the priviledge,
> you can use FreeBSD to do all this for you as well.
>
> At this point our network is composed of two subnets, 192.168.1.x, and
> 192.168.2.x. In order for the "Network Neighbourhood" to work properly=
> , a
> number of things need to be configured.
>
> 1. All your machines need to be configured to be in the same
> workgroup. For the rest of the examples I will use the workgroup
> name "WORKGROUP". You should, of course, change this to what ever
> you are using.
>
> 2. Each subnet needs to have a host acting as a "local master browse=
> r".
> This a Windows term. The local master browser is responsible for
> maintaining a list of all the hosts on the network. When a Windo=
> ws
> machine needs to find a list of all the other hosts on the network
> it sends a broadcast message out saying "Who is the local master
> browser?". The local master then replies, and the Windows host c=
> an
> then query the local master for a list of all the hosts on the sa=
> me
> subnet.
>
> There should be one local master browser per subnet.
>
> 3. Of course, this only works within a subnet. In order for this to=
> =20
> work across subnets, one host has to be the "domain master
> browser". The domain master browser maintains a complete list of
> all the hosts on all the subnets. This is done by having all the
> local master browsers send it updates periodically. Without a
> domain master browser your Network Neighbourhood will not show up
> hosts in other subnets.
>
> There should only be one domain master browser.
>
> 4. Windows network is based on the Netbios protocol. This has a
> concept of hostnames, but it is different from the IP concept of
> hostnames. Netbios name look ups do not normally work across
> subnets.
>
> In order to work around this, one machine (and only one) machine
> should be designated a "WINS Server". The WINS Server is normally
> the same host as the domain master browser. It is the
> responsibility of the WINS Server to maintain the mapping of Netbios
> host names to IP addresses. Without this mapping, your Network
> Neighbourhood will show hosts in other subnets (because of the local
> master browser -> domain master browser communication) but your
> Windows hosts in another network will not be able to communicate
> with them, because they will not be able to convert their Netbios
> names in to IP addresses.
>
> There can only be one WINS Server per network (note: not per subn=
> et,
> per network), and every other host needs to know its IP address.
>
> That's the bare minimum you need to get started. Now you need to design
> your network.
>
> For the sake of this example, we will assume that you have two more
> FreeBSD hosts, one on each subnet. Lets give these the IP addressess
> 192.168.1.2 and 192.168.2.2 respectively, and make them responsible for
> coordinating the Windows network and allowing browsing across the VPN to
> work. These machines might also have file shares on them, but this
> article will not touch on that, as it's trivial to set up, and well
> documented.
>
> Recall that we will need two local master browsers, one domain master
> browser, and one WINS server.
>
> To keep things simple, 192.168.1.2 will be a local master browser, the
> domain master browser, and the WINS Server. 192.168.2.2 will be the lo=
> cal
> master browser for its network, and will send updates to the domain mas=
> ter
> browser.
>
> You should install Samba, from ports/net/samba/, on both hosts. Samba's
> configuration file is ${PREFIX}/etc/smb.conf.
>
> Both hosts will share some configuration information, since they will b=
> oth
> be acting as a local master browser.
>
> Edit ${PREFIX}/etc/smb.conf and add the following lines:
>
> [global]
> ; The network workgroup
> workgroup =3D WORKGROUP
>
> ; The name for this server, as it will appear in the=20
> ; Network Neighbourhood
> server string =3D Samba Server
>
> ; Hosts that will be allowed to access this server
> hosts allow =3D 192.168.1. 192.168.2. 127.
>
> ; Template for generating log files
> log file =3D /var/log/log.%M
>
> ; This host is a local master. It is the preferred master, and the
> ; os level is set high enough that it will be chosen in preference
> ; to every other host on the network, should that eventuality
> ; arise.
> local master =3D yes
> preferred master =3D yes
> os level =3D 65
>
> The per-host configuration is as follows.
>
> 192.168.1.2 is the WINS Server and domain master. Add these lines to t=
> he
> bottom of the "[global]" section in the configuration file.
>
> ; This host is the domain master for the whole network.
> domain master =3D yes
>
> ; This host will act as a WINS Server.
> wins support =3D yes
>
> 192.168.2.2 is neither of these. The lines to add for that are
>
> ; This host will not be the domain master.
> domain master =3D no
>
> ; This host is not a WINS Server, but it needs to know the address
> ; of the WINS Server
> wins server =3D 192.168.1.2
>
> Make sure that the Samba daemons (smbd(8) and nmbd(8)) are running on b=
> oth
> machines.
>
> Now you need to configure your Windows client machines. Specifically,
> they need to know the address of the WINS Server (192.168.1.2). There =
> are
> two ways you can do this.
>
> 1. If you are 'statically' configuring the hosts then this informati=
> on
> can be entered by doing Start -> Control Panel -> Network -> ...
>
> 2. Alternatively, if you are using DHCP then must DHCP servers can
> be configured to provide this information. If you use the ISC DH=
> CPD
> then the relevant line to add to the configuration file is=20
>
> options ...
> --=20
> FreeBSD: The Power to Serve http://www.freebsd.org/ (__)
> FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',)
> \/ \=
> ^
> --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/=
> _)
>
> --L0TNCHh3fkwjpuuE
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (FreeBSD)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjyvHNAACgkQk6gHZCw343U5ogCdFF4HViejvE/Yt74SdB/2vRh9
> 9c8AnA8wy+JL7g35a8021HcxgFhXuVK9
> =XYDt
> -----END PGP SIGNATURE-----
>
> --L0TNCHh3fkwjpuuE--
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-doc" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CAF7B92.3060100>