Setting up a VPN between firewalls

Virtual Private Networking (VPN) capabilities are built into the majority of firewall devices these days and they're an immensely useful mechanism for connecting people with their data.

There are two basic types of VPN. A user-to-network VPN links a user's personal computer into the corporate network by making an encrypted connection between the computer itself and the office network. This type of connection requires the computer to understand how to communicate using VPN protocols - either using in-built software (e.g. the PPTP VPN client that ships with Windows 98 and above) or a proprietary VPN client package.

A network-to-network VPN links two networks together, and relies on there being a device at each end of the connection that handles the VPN wizardry (which means that the various connected computers don't even know there's a VPN there). We'll look at user-to-network VPNs in a future How To, in this one we'll look at setting up a network-to-network VPN.

Understanding what's happening
In a network-to-network ("N-N") VPN, the VPN device is usually the firewall that separates the LAN from the Internet and so we're going to use this model for our example. We'll emulate connecting a user's home office with the corporate centre; the former is using a NetScreen-5GT SoHo firewall, the latter a NetScreen-50 enterprise unit.

The two main aspects to VPNs are encryption (encoding the data before sending over the wires, in case someone is sniffing about) and authentication (ensuring that traffic is coming from someone we know and trust). There is a third, less-talked-about issue with VPNs, though, and that's routing.

We said in the introduction that in an N-N VPN, the users' computers don't need to know anything about the existence of a VPN. This is because the VPN devices themselves are performing some routing sleight-of-hand and pretending to their client computers that there's actually just a point-to-point link there. Imagine the following network.

Let's assume our world has the following setup:

- A PC in the home office with IP address

- A firewall in the home office with "trusted" address and "untrusted" address, with the "untrusted" interface connected to the Internet.

- A firewall in the central office with "trusted" address and "untrusted" address, with the "untrusted" interface connected to the Internet.

- A server in the central office with IP address

You'll notice that the external addresses of the devices are actually in the same class C subnet - this is because in our lab the units are connected back-to-back instead of being at opposite ends of the country. This is fine for our purposes, though - the operation of the units is no different when they're in the same room from when they're hundreds of miles apart.

With our pair of NetScreens, as with most similar units, we have a wizard on each firewall to help us with the configuration process, and it leads us through a number of steps.

First, it asks which interfaces we want to use as the internal and external interfaces for each setup; fairly obviously, we choose the "trusted" interface to be the internal port and the "untrusted" one to be the external in each case.

Next, we're asked whether we want to create a new "virtual interface" (the "virtual" port that packets to the remote end will be passed down) for the new VPN and we'll say that we do. Imagine we had a pair of traditional routers connected together by a direct link, each end of the link would be connected into a port on the router. The way these particular devices work is to create the VPN connection so that it looks like an actual network port as far as the underlying operating system is concerned - we'll get to why that is in a moment.

Next, we need to tell each firewall the IP address of the external interface of its distant partner - so that each unit knows to which address it should direct packets that are destined for the other end. So we tell the home office unit that it should send to, and the central office unit that it should use

Here's the trick with the VPN, then. We said in the previous step that as far as the firewall's operating system is concerned, each VPN "tunnel" looks like a network port as far as the routing software is concerned. The only trouble is, with a direct link the system doesn't need to know anything about where the other end is - it drops packets on the wire and assumes they'll get to the other end. This isn't the case with a VPN - the other end is somewhere on an arbitrary network - and so we have to tell each system's underlying VPN driver (the gizmo that's pretending to be a WAN connection) the IP address it should send its packets to.

Next, we're asked to give each firewall a "pre-shared secret"; this is a (preferably long) string of characters that the two units will exchange when the connection is made, to verify the identity of the remote partner. No rocket science here - the VPN driver needs to be sure that the caller is who it says it is.

Next, we need to tell each unit which addresses are local ( for the home office, for the central) and which are remote ( for the home office, for the central). This is just like making an entry in the routing table (in fact, that's pretty well what the wizard will be doing once we click "OK") that says "Network X is local, and lives on the "trusted" interface, and network Y is distant, and lives on the virtual VPN interface).

Nearly there now. The NetScreen wizard asks us whether we want to impose any scheduling on the VPN link - to restrict its use to certain times of the day, for instance. We don't, so we can leave this blank. The other thing it'll ask is whether we want to restrict the types of traffic (mail, Web, etc) flying down the link, but we'll assume that we want our remote user to feel like he's sat on the office network, so we'll tell it to pass everything.

Once the wizards are completed, we can start to test stuff. A good thing to do when you're setting up VPNs is to enable the various interfaces to respond to "pings" – that way, if something doesn't work, you can test each step of the way between source and destination using basic tools to see if something's gone wrong. The other thing you should do is set up logging on both units, so that they report what's going on with the various connection setup attempts; we generally use the Unix "syslog" protocol, as it's commonly supported and we have loads of Linux machines lying around that we can use as logging servers.

To make the VPN connection happen, if it doesn't wake up on its own, you simply have to attempt to connect from a machine at one end to a machine at the other. So you could try pinging the server in the central office from the machine at the remote office:

The log file confirms that everything is going OK but if something was awry, it would tell us that too. In fact, you should see similar content in the log files at both ends - this snippet happens to come from the one at the central office and shows the progress of the negotiation of the VPN connection setup:

Mar 3 17:17:22 ns50: NetScreen device_id=ns50 [Root]system-information-00536: IKE<> Phase 1: Responder starts MAIN mode negotiations. (2004-03-03 09:24:23)
Mar 3 17:17:22 ns50: NetScreen device_id=ns50 [Root]system-information-00536: IKE<> Phase 1: Completed Main mode negotiations with a <28800>-second lifetime. (2004-03-03 09:24:23)
Mar 3 17:17:22 ns50: NetScreen device_id=ns50 [Root]system-information-00536: IKE<> Phase 2 msg ID : Responded to the peer's first message. (2004-03-03 09:24:23)
Mar 3 17:17:22 ns50: NetScreen device_id=ns50 [Root]system-information-00536: IKE<>: Received a notification message for DOI <1> <40001> . (2004-03-03 09:24:23)
Mar 3 17:17:22 ns50: NetScreen device_id=ns50 [Root]system-information-00536: IKE<> Phase 2 msg ID : Completed negotiations with SPI <96162199>, tunnel ID <1>, and lifetime <3600> seconds/<0> KB. (2004-03-03 09:24:23)

Because we've turned on verbose logging, the unit also confirms that stuff's happening when we attempt to make connections. This line is confirmation that the central office firewall has granted access to an incoming FTP connection from the remote office.

Mar 3 17:18:28 ns50: NetScreen device_id=ns50 [No Name]system-notification-00257(traffic): start_time="2004-03-03 09:25:08" duration=22 policy_id=2 service=ftp proto=6 src zone=Untrust dst zone=Trust action=Permit sent=78 rcvd=0 src= dst= src_port=32778 dst_port=21 src-xlated ip= port=32778

Obviously different devices operate differently when it comes to setting up VPN connections. The majority of modern firewalls have some kind of hand-holding approach such as a wizard (or even just a quick-start manual that walks you through the process). The trick to getting VPNs working, and particularly debugging them, though, is to understand how they work underneath - mainly a case of getting to grips with the fact that a VPN is often implemented as a "virtual" network port under which sits the trickery that handles the actual remote connection, authentication and encryption.

This story, "Setting up a VPN between firewalls" was originally published by

Copyright © 2010 IDG Communications, Inc.

Shop Tech Products at Amazon