pfSense Multi-WAN Configuration: Part Four

pfSense multi-WAN

Setting up multi-WAN load balancing with failover in pfSense 2.2.4

The load balancing functionality in pfSense allows you to distribute traffic over multiple WAN connections in a round-robin fashion. This is done on a per-connection basis. A monitoring IP is configured for each connection, which pfSense will ping, if the pings fail, the interface is marked as down and removed from all pools until the pings succeed again.

pfSense Multi-WAN: Load Balancing 

In pfSense 2.0 and above, Services -> Load Balancer is not used to configure load balancing with a multi-WAN setup. Instead, we use Gateway Groups by navigating to System -> Routing and clicking on the Groups tab. Click the plus button to add a new gateway group.

In the Group Name field, you can enter a group name. The Gateway Priority section is where you configure load balancing. The Tier field determines the link priority in the failover group. Lower-numbered tiers have priority over higher-numbered tiers. Multiple links of the same priority will balance connections until all links at that level are exhausted. If all links in a priority level are exhausted, pfSense will use the next available link in the next priority level.

To illustrate how this works, I created three gateways: WAN, WAN1 and WAN2, as can be seen in the screen capture. Let’s assume that the WAN gateway is my main Internet connection (e.g. a cable modem). Assume that the WAN1 and WAN2 gateways are for my backup Internet connections (e.g. DSL). We want WAN to provide our primary connection to the Internet. When WAN is down, we want our Internet connectivity to be load balanced across WAN1 and WAN2. Therefore, we set WAN to Tier 1 and both WAN1 and WAN2 to Tier 2. Thus, when the higher priority WAN is down, the failover will user WAN1 and WAN2. If either WAN1 or WAN2 go down, pfSense will use the remaining functioning gateway, so that even if two of the gateways are down, we should have some Internet connectivity, albeit with limited bandwidth.

The next field in the table, Virtual IP, allows you to select what virtual IP should be used when the gateway group applies to a local Dynamic DNS, IPsec or OpenVPN endpoint. In my example, since I was not setting up the gateway group to be used in any such scenario, I left this field unchanged.

The next field, Trigger Level, allows you to choose which events trigger exclusion of a gateway. The choices are Member Down, Packet Loss, High Latency, and Packet Loss or High Latency. I chose Packet Loss as the trigger. You can enter a brief Description, and press the Save button. On the next page, you’ll need to press the Apply Changes button.

Next, you need to redirect your firewall traffic to the new gateway. Navigate to Firewall -> Rules, and click on the tab of the interface whose traffic you want to redirect (e.g. LAN). Press the plus button to add a new rule. The default settings can be kept for most settings (Source and Destination should both be set to any). Scroll down to Advanced features, and press the Advanced button in the Gateway section. Select the gateway set up in the previous step in the dropdown box. Enter a brief Description, and press the Save button. On the next page, press the Apply Changes button. If you need to redirect traffic on other interfaces, you will have to set up firewall rules for those interfaces as well.

Finally, you need to navigate to System -> General Setup and make sure you have at least one DNS server for each ISP. This ensures that you still have DNS service if one or more gateways goes down. You may need to set up static routes for your DNS servers; part two of this series went into some detail on how to do this.

Once the gateway groups and firewall rules are configured, your multi-WAN load balancing setup should be complete.

External Links:

Network Load Balancing on Wikipedia

Video: Configuring Dynamic DNS with pfSense

You may want to set up a domain name for your home or SOHO WAN IP. This video demonstrates how to do this. In this video I cover:

  • What DDNS is, why you might want to use it, and different methods of implementing DDNS
  • Configuring Duck DNS on the Duck DNS web site; downloading and installing the Duck DNS client
  • Configuring DDNS in pfSense and setting up NAT so we can access an Apache web server behind the firewall
  • Accessing a web site using the domain name I set up in the previous steps

IPsec VPN Configuration in pfSense: Part One


Phase 1 IPsec configuration in pfSense 2.2.4.

In the previous article, we covered how to set up a PPTP VPN connection in pfSense, and how to connect to it in Mint Linux. Since PPTP relies on MS-CHAPv2, which has been compromised, we probably want to use another method if security is paramount. In this article, we will cover setting up an IPsec tunnel with pfSense and connecting to it with Mint Linux.

IPsec VPN Configuration: Phase 1

First we need to set up the IPsec tunnel in pfSense. Navigate to VPN -> IPsec and click on the plus button on on the lower right to add a new tunnel. Under General information, there is an entry for Interface, where we select the interface for the local endpoint of the tunnel. Since our end user will be connecting remotely, the local endpoint should be WAN. The next entry is Remote Gateway, where we enter the IP address or host name of the remote gateway. Enter a brief description and scroll down to the Phase 1 proposal (Authentication) section. At Pre-Shared Key, you need to enter a key (PSK), which will essentially be the tunnel’s password. Whether you alter the Phase 1 proposal (Algorithms) settings or not, take note of the settings, as we will need them for future reference. Press the save button at the bottom to save the Phase 1 configuration. On the next page, press the Apply changes button to commit changes.


Phase 2 IPsec configuration.

IPsec VPN Configuration: Phase 2

Now there should be a new entry in the IPsec table for the new Phase 1 configuration. Click on the big plus button underneath the entry you just created to initiate Phase 2 configuration. This section should expand, revealing an empty table for Phase 2 settings. Click on the (smaller) plus button to the right of the table to bring up the Phase 2 settings page. For Mode, you can select whichever method you prefer, but note that whoever connects will have to use the same method. For Local Network, enter the network or address to which you want to give the VPN user access (probably LAN net). For Remote Network, enter the address of the remote end of the VPN tunnel. Enter a brief description. In the Phase 2 proposal section (SA/Key Exchange), set the protocol and encryption options, again taking note of them for future reference (AES-256 is the commonly used standard). When you are done, press the Save button at the bottom of the page. Press the Apply changes button on the next page to commit changes. Finally, check the Enable IPsec check box on the main IPsec page and press the Save button.

Now that Phase 1 and Phase 2 configuration are complete, all that remains is to create a firewall rule for IPsec traffic. Navigate to Firewall -> Rules. There should be a new tab for IPsec; click on it. There may already be a rule there allowing traffic to pass to whatever network or address you specified in the Phase 2 configuration. If not, then create one now by pressing the one of the plus buttons on this page. Most of the default settings can be kept, but set Destination to the network or address specified in Local Network in the Phase 2 configuration. For Destination port range, specify any. Add a brief description, and press the Save button. On the next page, press the Apply changes button to commit these changes.

In part two of this article, we will cover connecting to the VPN tunnel from the remote node.

External Links:

IPsec on Wikipedia

pfSense IPsec configuration information from the official pfSense site

Securing Ports and Services

Securing portsA computer system that is not connected to a network is a rarity. While this provides some flexibility in terms of remote services, data and information that are available, it also brings considerable risks. It is probably correct to assume that any computer connected to a network is in danger of being attacked in some way. Secure computer environments, in many cases used by government defense organizations, often have no contact with the outside world, even if they are networked to each other, and as a result, they often have greater success in securing ports and services.

The predominant network communications protocol is TCP/IP. It is the protocol used by the Internet and thus has supplanted most of the formerly popular protocols used for local area networks (LANs). However, TCP/IP was conceived to send and receive data reliably, not to secure it. Securing the data (and securing ports) is the job of applications listening and sending on specific ports.

TCP/IP defines a total of 65,535 ports of which 1023 are considered to be well-known ports. These are, of course, not physical ports into which network cables are connected, but rather virtual ports on each network connection which can be used by applications and services to communicate over a TCP/IP connection. In reality, the number of ports that are used by popular network clients and services comprises an even smaller subset of the well-known group of ports, which makes the task of securing ports somewhat easier.

There are a number of different TCP/IP services which can be provided by an operating system. Such services include HTTP for running a web server, FTP for allowing file transfers, SSH and Telnet for providing remote login access and SMTP for the transport of e-mail messages. Each service in turn is assigned a standard TCP/IP port. For example, port 80 is for HTTP requests; port 21 is for File Transfer Protocol (FTP); port 17 is for the quote of the day.

Securing Ports and Services: How It’s Done

A large part of securing ports and securing servers involves defining roles, and based on the roles, defining which services and ports should be enabled. For example, a server that is to act solely as a web server should only run the HTTP service, and perhaps SSH for remote administration access. All other services should be disabled, and ideally, removed entirely from the operating system. Removing the service will make it harder for an intruder to re-enable the service. Thus, while it is necessary for some ports to be open to Internet traffic, it is also necessary to ensure that only the bare minimum are exposed and that the software on the system is as up to date as possible.

Securing a system involves (a) removing any unnecessary services from the operating system and (b) ensuring that the ports associated with these non-essential services are blocked using a firewall.

Many operating systems are installed with a number of services installed and activated by default. Before installing a new operating system, it is essential that the installation be carefully planned. This involves deciding which services are not required and identifying which services have been installed and enabled by default. It helps if deployment is not rushed; the fewer services and open ports available on a system, the smaller the surface area and opportunities for attackers. In addition, it is essential to turn on automatic updates, both for Windows and Linux, as well as for your antivirus software.

As for the firewall, you will want to have a dedicated firewall between your network and the Internet. Although not absolutely essential, it is good practice to have a personal firewall on each computer. In securing ports, you should make sure your firewall is closed to all traffic other than to the ports you know should be open. Because some malicious software can silently open ports, it is a good idea to check them yourself and close any that you do not need open.

External Links:

TCP/UDP ports on Wikipedia

How to secure your TCP/IP ports at

IP Spoofing and Defenses

IP spoofingIP address spoofing is the creation of IP packets with a source IP address with the purpose of concealing the identity of the sender or impersonating another computer system. The basis of spoofing involves masquerading as a trusted system in order to gain unauthorized access to a secure environment. IP spoofing involves modifying data to make it appear to originate from the IP address of a system that is trusted by a server or firewall. Using this approach, a host is able to pass through the IP filtering that would otherwise serve to prevent access.

The objective of IP spoofing in most, but not all cases, is to gain unauthorized access to a server or service. DNS spoofing differs from IP spoofing in that the objective is to send users to a different location than the one to which they thought they were going. For example, assume a user wants to login to Facebook. He enters the URL of Facebook into his browser. The browser contacts a Domain Name Server (DNS) which looks up the IP address which matches the URL. The user is then taken to the site located at that IP address, where he enters his login name and password. DNS spoofing involves the DNS server being compromised such that the Facebook URL is set to point to the IP address of a malicious party where a web site that looks like Facebook has been set up. Now when the user enters the URL in a browser, he is taken to the fake web site where his login name and password are captured and stored. The web site might then report that Facebook is offline for maintenance. The user decides to try again later. In the meantime, the attacker uses the victim’s credentials to log into his Facebook account and gain a foothold in committing identity theft. Even more nefarious would be if the attacker used DNS spoofing to point to a fake bank web site or another site where the attacker may be able to gain access to sensitive data.

IP spoofing is not, however, always carried out with malicious intent. In performance testing of websites, hundreds or even thousands of virtual users may be created, each executing a test script against the web site under test, in order to simulate what will happen when the system goes live and a large number of users log on at once. Commercial testing products can use IP spoofing, allowing each user its own IP address.

IP Spoofing: Defenses

There are several possible defenses against IP spoofing. Packet filtering is one defense against IP spoofing attacks. The gateway to a network usually performs ingress filtering, which is blocking of packets from outside the network with a source address inside the network. This prevents an outside attacker spoofing the address of an internal machine. Ideally, the gateway would also perform egress filtering on outgoing packets, which is blocking of packets from inside the network with a source address that is not inside. This prevents an attacker within the network performing filtering from launching IP spoofing attacks against external machines. In addition, many firewalls (pfSense included) practice bogon filtering, which means that IP packets from the Internet that claim to be from an area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR), are blocked.
Some upper layer protocols provide their own defense against IP spoofing attacks. For example, Transport Control Protocol (TCP) uses sequence numbers negotiated with the remote machine to ensure that arriving packets are part of an established connection. Since the attacker normally cannot see any reply packets, the sequence number must be guessed in order to hijack the connection.

Implementing encryption and authentication will also reduce spoofing threats. Both of these features are included in Ipv6, which will eliminate current spoofing threats. Additionally, a system administrator should eliminate all host-based authentication measures, which are sometimes common for machines on the same subnet. You should ensure that the proper authentication measures are in place and carries out over a secure, encrypted channel.

IP spoofing is a common problem without a simple solution, since it is inherent in the design of the TCP/IP protocol suite. Understanding how and why spoofing attacks are used, along with a few simple prevention methods, can help protect your network from these nefarious techniques.

External Links:

IP spoofing on Wikipedia

MailScanner Installation and Configuration: Part One


MailScanner configuration under pfSense 2.1.3.

MailScanner is an e-mail security and anti-spam package for e-mail gateway systems. It is not designed to be run on Microsoft Windows desktop PCs. Instead, it is designed to be run on mail servers operated by companies and ISPs so that all their users and customers can be protected from one place. This avoids the need for any software to be installed on individual desktop PCs at all. The software works with any Unix-based system and is compatible with a wide range of mail transports, and comes with support for any combination of 25 different virus scanner packages, including the free ClamAV scanner.

MailScanner is implemented in around 50,000 lines of Perl. It links with other software packages in order to perform its functions:

  • E-mail server (e.g. sendmail)
  • Anti-virus software (e.g. ClamAV)
  • Anti-spam software (SpamAssassin)

MailScanner Installation

To install MailScanner under pfSense, navigate to System -> Packages, and scroll down to “Mailscanner” in the package list. Press the “plus” button to the right of the listing, and on the next page, press the “Confirm” button to confirm installation. It will take a few minutes for the Package Installer to extract and install MailScanner.

Once MailScanner is installed, there will be a new entry on the “Services” menu called “MailScanner”. If you navigate to it, you will be able to modify several settings. There are 9 tabs: “General”, “Attachments”, “Antivirus”, “Content”, “AntiSpam”, “Alerts”, “Reporting”, “XMLRPc Sync”, and “Help”. Under the “General” tab, the first heading is “System Settings”. The “Enable Mailscanner” check box will enable the mailscanner daemon if checked. “Max Children” allows you to choose how many MailScanner processes you want to run at a time (the default is 50. “Processing Incoming email” allows you to either scan messages or reject messages.

In the “Logging” secion, “Syslog Facility” allows you to specify what type of program is logging the message. The default is “mail”, and that is probably what you want to leave it at, but there may be circumstances when you may want to specifiy a different Syslog facility. See the Syslog entry on Wikipedia for a list of facility levels, or read RFC 1164 for more information. The “Logging” list box allows you to choose which messages to log.

“Advanced Settings” has some additional options. “Advanced features” allows you to select several options. By default, only “Deliver in Background” is selected. “Deliver Method” allows MailScanner to attempt immediate delivery of messages, or just place them in the outgoing queue for the MTA to deliver when it wants. “Minimum Code Status” lets you set the minimum acceptable code status; if MailScanner comes across a code that is not at least as stable as what it set here, it will stop running.

In the next article, we will continue our look at MailScanner’s settings.

External Links:

The official MailScanner web site
MailScanner at Wikipedia

pfSense Installation: A Scrounger’s Guide (Part Two)

pfSense installation

The computer I used as my new pfSense box.

In the last article, I discussed my project to turn an old computer into a pfSense firewall and set some guidelines for the project. In this article, I get to configuration of the pfSense box and pfSense installation.

pfSense Installation: Selecting the Hardware

As you recall from part one of this series, the base system requirements for a pfSense installation are:

  • Pentium II or better
  • 256 MB RAM
  • 1 GB of disk space for a standard installation; 512 MB of disk space for embedded systems

I immediately realized the system I used for m0n0wall would not make the grade (too slow and not enough memory). However, I had another old system that might work. I had a Pentium III (733 MHz) with 256 MB RAM. The motherboard for this system died a few months ago; I found a replacement on eBay (for $15), but the system has been running slow ever since. It seemed like an ideal candidate for conversion to a pfSense firewall.

Since I did not want to erase the contents of the original hard drive, I had to find another one to install into the system. I went through a box of old hard drives and found a Western Digital Caviar 22000. With 2 GB of disk space, it had more than enough space for pfSense. I swapped out the original hard drive with the Western Digital.

The next consideration was what network cards to install on the system. You need at least two NICs: one for the WAN and one for the LAN. Installing a third NIC allows you to have an OPT1 interface for a DMZ. Fortunately, there was already one Intel Pro 100 NIC in the computer, and I had a spare two. The Intel Pro 100s are PCI cards, and there are three PCI slots on this motherboard, so I used up all the available PCI slots, but that shouldn’t be a problem. If you need to buy NICs, the folks at recommend purchasing Intel cards (or systems with built-in Intel NICs) up to 1 Gbps. It would behoove you to by Intel PRO 1000s, at least for the LAN and OPT1 interfaces (on the WAN side, using a 100 Mbps NIc will not create a bottleneck for most residential broadband customers). A quick eBay search revealed than PRO 1000s are available for less than $10 (for both PCI and PCI-X interfaces). My Neoware thin client has a 1 Gbps 2-port NIC for the LAN and OPT1 interfaces, and a 100 Mbps NIC for the WAN interface. An upgrade to Intel PRO 1000s on this system is definitely something I will consider in the near future.

pfSense installation

The Compaq Deskpro motherboard recognizes the Samsung drive, so we can proceed.

With the hard drive and NICs installed, I was ready to move the computer over to the test bench and begin pfSense installation. After running setup to make sure the BIOS recognized the Western Digital drive, I put the pfSense CD in and booted the system. When prompted whether to boot pfSense from the CD or run the installer, I hit “I” and invoked the installer. This is where I had my first real setback: although the motherboard’s BIOS recognized the Caviar, pfSense did not, and I therefore could not install pfSense onto it. Fortunately, I had a Samsung sW0434A (total capacity: 4.3 GB) I could install (again courtesy of the box of old hard drives), so I powered down the system and replaced the Western Digital with the Samsung.

pfSense Installation: Options

Once the hard drive had been replaced, I was able to boot pfSense from the CD and begin pfSense installation. When the installer starts, you have a chance to change the video font, change the screenmap, change the keymap, or accept the settings. Since I had no reason to change the defaults, I chose “Accept These Settings“.

On the next screen, you have a choice between quick/easy install and custom install (there are also options to rescue config.xml and reboot). In most cases you can opt for the quick/easy install, but if you do not want to reformat the hard drive, or if you want to partition the hard drive onto which pfSense is installed, or specify a different hard drive geometry than what was detected by pfSense, you want to opt for the custom install. I just wanted to reformat the hard drive and install pfSense onto it, so I opted for “Quick/Easy Install“.

Next, the pfSense installer will give you a choice between installing the standard pfSense kernel, or the embedded kernel (which has no vGA console or keybaord available). I selected “Standard Kernel” and continued. After a few minutes, pfSense was installed, and I was prompted to reboot the system. With pfSense installation complete, I rebooted the system and was ready to run pfSense on this computer for the first time.

When pfSense runs for the first time, it will ask you to assign interfaces. I assigned fxp0 for the WAN and fxp1 for the LAN. [I opted to set up OPT1 from the web configurator, later on]. I also assigned the IP address for the LAN interface.

By now, pfSense installation and configuration was complete, and I had a fully functional pfSense box, but I hadn’t connected it to my network. That’s no fun, so in the next article, I will talk about what happened when I used the new system as my firewall.

External Links:

pfSense Hardware at

Intel PRO/1000 GT Desktop Adapter – Overview at

pfSense Hardware: A Scrounger’s Guide (Part One)

pfSense hardware

The Pentium P-233 that served as my m0n0wall firewall/router

When I started using pfSense as my primary firewall, it replaced my previous firewall solution: a Pentium P-233 running m0n0-wall. I eventually switched to a Neoware thin client running pfSense, which I ultimately upgraded to version 2.1.3. The Neoware thin client meets the pfSense hardware requirements for running pfSense on an embedded system, and offered pretty good value for the money – one would be hard-pressed to put together a system more cheaply than these pfSense appliances which has the same features and functionality. Yet while running pfSense from a thin client may be the best option for some users, if you have an old computer that meets the pfSense hardware requirements, this may be the better option. For that reason, I thought it would be an interesting exercise to see how easy (or how hard) it is to turn an old PC into a pfSense firewall.

Indeed, the system I used to run m0n0wall had been scrounged from spare parts. The case and power supply had come from an old barebones system I had bought in the late 1990s. The motherboard/CPU was one of a lot of three I had bought on eBay a few years later, and the CD-ROM was from a group of spare CD-ROM drives I had, as was the floppy drive. I only had 32 MB of RAM initially. I found that with only 32 MB of RAM installed, m0n0wall’s web-based configurator would eventually crash (although the firewall itself would continue to function). I found another 32 MB of RAM on eBay for a few dollars, and my system was complete. The NICs had also been taken from old computers, although I eventually bought a lot of 10 Intel Pro 100 cards for $35. As underpowered as this system might seem, it served ably as my firewall for several years. Thus, I began to wonder if I had any old hardware that could run pfSense, and decided that for my next mini-project, I would take an old computer and turn it into a serviceable pfSense router.

pfSense Hardware: The Guidelines

For this project, I set out some basic guidelines:

  1. The hardware had to meet the general requirements for pfSense hardware. These requirements are listed on the official pfSense web site. For any installation, a Pentium II or better with at least 256 MB of RAM is recommended. For hard drive installations, a 1 GB hard drive is required (and a CD-ROM drive for installation).
  2. When possible, I would scrounge from existing resources to put together a system that would serve as my new pfSense box. If necessary, I would buy new hardware, but only as a last resort.
  3. I was not completely sure what the final system would have installed on it, but I knew at a minimum I wanted to have the most recent pfSense version (2.1.3 at this writing), and probably Squid, SquidGuard, and probably some other packages.
  4. To the fullest extent possible, I would document the process, so I would have a record of what worked (and what didn’t work).

These guidelines should provide a rough road map for this project. In the next article, I will cover the selection of hardware, putting together my pfSense box, and installing pfSense onto it.

External Links:

Hardware for pfSense at – pfSense hardware requirements guide

VPN Access Strategies

VPN accessA virtual private network (VPN) is exactly what it sounds like: the network connection you create is virtual, because you can use it over an otherwise public network. Basically, you take two endpoints for the VPN tunnel, and all traffic between these two endpoints will be encrypted so that the data being transmitted is private and unreadable to the system in between. Different VPN solutions use different protocols and encryption algorithms to accomplish this level of privacy. VPNs tend to be protocol independent, at least to some degree, in that the VPN configuration is not on a per-port basis. Rather, once you have established the VPN tunnel, all applicable traffic will be routed across the tunnel, effectively extending the boundaries of your internal network to include the remote host. In this article, we will examine some of the issues involved in implementing VPN access.

VPN Access: Network Design

One of your first considerations when planning to provide for VPN access is the network design. Because the VPN tunnel needs two endpoints, one will be the remote workstation. The other will be a specially configured device for that purpose. This is generally called a VPN concentrator, because it acts as a common endpoint for multiple VPN tunnels. [As noted previously in this blog, Soekris makes affordable VPN cards that offload the CPU of the the computing intensive tasks of encryption and compression.] The remote system will effectively be using the concentrator as a gateway into the internal network; as such the placement of the concentrator is important: in a highly secured environment, the concentrator is placed in a DMZ sandwiched between two firewalls, one firewall facing the Internet, and the other facing internally. While this type of arrangement is the most secure, it takes more hardware to implement.

Another way to place the VPN concentrator inside a DMZ is to use an additional interface on the firewall as the DMZ in a “one-legged” configuration. This saves you having to implement an additional firewall, but still provides some isolation between the concentrator and the rest of the internal network. If an attacker compromised a remote host who was VPNed into the concentrator or compromised the concentrator itself, they would still have a firewall between them and the internal network. The least preferable option is to place the concentrator inside the internal network. With this type of design, if the concentrator is compromised, the attacker would have full access to the internal network, with no firewalls to inhibit their activities. With any of these designs, you will have to permit the required ports through the firewall and forward them to your VPN concentrator in order to ensure VPN access.

VPN Access: Protocols

Another consideration in providing VPN access is the type of VPN protocol you want to use. IPsec is still the most widely deployed VPN technology for good reason. One is interoperability. As a widely used and tested standard, IPsec will work with virtually any modern firewall and operating system. The disadvantage of IPsec is that it can sometimes be difficult to configure properly, and there is zero margin for error on the configuration. Both ends have to se the same parameters for encryptions, hashing, and so forth, or the tunnel cannot be established. SSL is an increasingly popular choice for VPNs, largely because of its simplicity to implement.

Once you have chosen a design and VPN technology, you need to consider the administrative ramifications of offering remote access. Some level of training will be required. At the very least, they may require training to use the VPN software. It is a good idea to educate your users on good security habits as well. A determination will also need to be made as to whether remote users are allowed to use their own personal computers and/or laptops, or if they must use a company-provided computer for remote access. The former option carries with it many risks. When a remote user connects their personal computer to the corporate network, they may have spyware, a virus, or any number or potentially damaging conditions present on their system. Due to the fact that you probably do not have any administrative access to their systems, you may have no way to secure the personal systems even if you wanted. This is why most companies require that only corporate resources be allowed to connect to the company network.

VPN Access: Hardware

One last consideration for VPN access is hardware selection. Normal workplace desktop applications place very little strain on even a remotely modern processor. The same is not true when it comes to VPN connections. A single VPN connection requires little overhead and rarely impacts the remote user’s system unless it is especially underpowered. For the VPN concentrator, however, it will handle the encryption and decryption of multiple connections, in addition to managing the volume of network data that will be accessed through it. For this reason, if you anticipate more than just a couple of VPN connections to be used simultaneously, you will want to test and evaluate your hardware needs.

Internal Links:

pfSense VPN: Part One

pfSense VPN: Part Two

pfSense VPN: Part Three (PPTP)

External Links:

An Overview of VPN Concentrators at YouTube (from CompTIA’s Network+ certification training)

How the VPN Concentrator Works at

Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.

Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy