The Netgate pfSense Certified firewall and VPN appliance for Amazon EC2 is a stateful firewall and VPN appliance. It is suitable for use as a VPN endpoint for mobile devices, laptops, and desktop computers to ensure that data sent over unsecured wireless networks or untrusted wired networks is encrypted using industry standard encryption algorithms. It can also be used to establish a connection between one or many sites with the internet or each other. It runs a custom version of pfSense, a stable and widely used firewall and VPN distribution based on the FreeBSD operating system. This AMI can be run in any region where EC2 offers service on various sizes of instance.
This guide will explain how to launch, manage, and use an instance of the appliance. For users who simply wish to use the default configured OpenVPN or IPsec VPNs, very little management of the instance should be necessary after the initial setup.
In the Amazon EC2 Management Console, launch a new instance of the Netgate pfSense certified firewall and VPN appliance.
Launch Instancebutton under the
Create Instancesection of the EC2 dashboard.
AWS Marketplaceon the
Create a New Instancemenu. Type
Netgate pfSense certifiedin the search box and press enter (or click on the
Searchbutton next to the text box).
Continuebutton on the info page for the Netgate pfSense certified firewall and VPN appliance.
Launch with EC2 Consoletab
Select a Version. Generally the most recently issued version should be selected. Identify which region you wish to launch the instances in and click on the
Launch in EC2 Consolebutton to the right of that region
Next: Configure Instance Details.
Configure Instance Detailspage or you can optionally expand the
Advanced Detailssection and set parameters as text in the
User Datafield. The available options are:
password - setting a value via a directive like
password=abcdefg will set the password for the administrative account to the value you specify - abcdefg in this example. If no value is set here, a random password will be assigned in order to keep administrative access from being exposed to the internet with a default password.
mgmtnet - setting a value via a directive like
mgmtnet=10.0.1.0/24 will restrict management access (http, https, ssh) to the network you specify - 10.0.1.0/24 in this example. This will cause the firewall rules on the instance (not on Amazons access lists, but on the Netgate appliance's own firewall) to restrict management traffic for the instance to the specified source network. The default behavior is to allow management from any host.
These directives can be set by placing them on a single line in the User Data field and separating them with colons. If you wanted to specify both parameters, you could do this by typing a statement similar to this one:
Next: Add Storage after optionally setting these parameters.
Note: If you set a password using the password parameter listed above, the password is retrieved by the instance via an unencrypted HTTP request when the system is configured the first time it boots. The request is made to an Amazon Web Services-operated server on the local LAN that stores metadata about each instance running. The data for an instance is only made available to that instance, but is available to be queried from the instance without providing any authentication credentials. It is advised that you change the admin password via the pfSense web GUI after the instance comes up if you judge this to be an unacceptable security risk. Or you may choose not to set the password at all and let a random password be set.
Next: Tag Instanceto accept the Storage Device Configuration.
Next: Configure Security Groupafter setting any desired tags.
If you have an existing security group that includes this access, select
Select an existing security group, then select the group(s) you want to use and click
Continue. Otherwise, select
Create a new security group, and add rules for this access by filling in the form for each rule and clicking the
Add Rule button. When all of the rules have been added, click
Review and Launch.
Proceed Without a Key Pair. Click the checkbox that indicates that you acknowledget hat you have access to the selected private key file and then click
Once the instance is launched, you can monitor its status on the Instances page of the EC2 Management Console. The EC2 Management Console will display whether the instance is up and reachable and will also display its current public IP address and the hostname that resolves to the public IP address. You can find the hostname and public IP address in the EC2 console by clicking on the
Instances heading on the left, finding the instance and checking the checkbox next to it and looking at the details at the bottom of the page.
In the example above, the hostname of the instance is
ec2-23-20-204-54.compute-1.amazonaws.com. The public IP address is available by putting together the 4 numbers included in the hostname -
184.108.40.206. You could also obtain the IP address by using a popular DNS lookup tool such as host, dig, or nslookup to resolve the hostname to its IP address.
Note: The hostname and IP address used in this and other examples in this guide are associated at the time of writing with a test instance. This address/hostname will not be the same values that you use to access your instance and they will not even be associated with the same test instance by the time this guide is available to the public.
In order to manage the configuration of the instance, you can connect to it via https or ssh. To connect via ssh, you would use the key pair you chose while creating the instance to connect to the admin account. From the command line on a Unix/Linux host, you would use a command similar to
ssh -i my_key_file admin@public_IP, where the appropriate private key file and public IP or hostname are substituted. In the example below, the key file my_ec2_key is used to connect to the IP address 220.127.116.11. Note that the first time you log into your instance, the ssh key of the instance will not be cached on your computer and you will need to type
yes when asked whether you want continue connecting. This should not be necessary on subsequent sessions.
A limited set of configurations is possible through the ssh interface. The preferred method for managing most of the configurations or viewing data on the status of the Netgate pfSense instance is through the https web GUI. To connect via https, you would enter an https:// URL containing the public IP address or hostname of your instance into a web browser. For example, https://18.104.22.168. It's very likely that you will receive a browser warning indicating that the security certificate of the site is not trusted. This is because the instance uses a self-signed certificate for https communication. You should click on the option to proceed to the site anyway. A login screen with the Netgate logo should appear.
The username to log in with is admin. The password to use is either a value that you set in the User Data during the creation of the instance or a random password. If you did not set a specific password, you can find out that value that the random password was set to through one of 2 different means. The first is to log in over ssh with the key pair that you selected when the instance was created and examine the contents of the file located at /etc/motd. You would do this by selecting option 8 (
Shell) from the console menu that is presented when you log in and executing
cat /etc/motd from the shell. Alternatively, you can view the System Log for the instance in the EC2 Management Console. After the messages that are displayed that show the status of the boot process, a message should appear that indicates what the administrative password was changed to.
The message you should look for using either of the methods mentioned about will look like this:
*** *** *** Admin password changed to: abcdefg *** ***
In this example, the password was changed to abcdefg.
Be aware that the System Log output in the EC2 Management Console is not updated in real time and may take a few minutes to show up. It is preferable to explicitly set a password by passing a value in with the User Data field so the password will be known in advance. If you want to allow a random password to be set, you should be able to connect via ssh and find out what the password was changed to after the instance is up without any delay.
Once you've determined your password and entered it into the login form, the pfSense Web GUI should be available to you.
An IPsec VPN for remote users is preconfigured on the instance when it comes up. In order to use it, you will need to configure the IPsec VPN client on your device. A guide for manually configuring Android or iOS (iPhone/iPod/iPad) mobile clients to establish an IPsec VPN is here:
For iOS clients, a profile can be downloaded and installed that will automatically configure an IPsec VPN to the instance. The profile can be downloaded by visiting the page at /iphone_ipsec_profile.php on the instance. If the instance IP address were 22.214.171.124, the correct URL to visit would be https://126.96.36.199/iphone_ipsec_profile.php. You will need to authenticate to the web interface by typing the username (admin) and password prior to being able to download the profile.
The profile should be downloaded and saved automatically upon opening the page. If the page is visited in a web browser on an iOS device, the device should automatically launch the Settings app and attempt to install the new profile. If the profile is downloaded to another non-iOS device, it can be sent via email as an attachment. If the attachment is opened in the iOS email client, the Settings app new profile installation will also open.
The name and description of the profile being installed will be displayed. Tap the
Install button. A warning message will be displayed that indicates that the profile is unsigned. Tap on
Install Now to continue.
Enter your passcode for the iOS device (the one you enter when you wake the device from sleep) and the password to access the IPsec VPN (the one you entered to get access to the Web GUI) when prompted and the profile will be installed. When the screen shows that the profile was installed, tap
When the profile has been installed, the VPN can be enabled in the Settings app. There will be a heading named
VPN under the main Settings page. If there are more than one VPN configured on the device, tap the VPN heading. The newly installed profile should be selected. It will have a check mark next to it. There will be an on/off switch at the top of the page to enable the VPN. If this is the only VPN configured, the switch to enable the VPN will be next to the VPN heading on the main Settings page. Tap the switch to enable the VPN. You should be prompted for a username and password. The username (admin) should already be filled in. Enter the password and tap
OK. A welcome message should be displayed. Tap
OK and you are ready to use the VPN.
An OpenVPN VPN for remote users is automatically configured the first time the instance is booted. In order to use it, you will need an OpenVPN client app installed on your device and you will need to import a configuration that specifies how to connect to the instance.
An OpenVPN configuration can be downloaded by visiting the page /openvpn_connect_profile.php on your instance. If the instance IP address were 188.8.131.52, the correct URL to visit would be https://184.108.40.206/iphone_ipsec_profile.php. You will need to authenticate to the web interface by typing the username (admin) and password prior to being allowed to download the configuration.
The profile should be downloaded and saved automatically upon opening the page. The file that it was saved in should be imported into the OpenVPN client on the device that you wish to connect with.
The iOS version of the OpenVPN Connect App allows you to import an OpenVPN profile by opening an attachment to an email message. Save the config to a file named remote-access-vpn.ovpn and send it to an email account that the iOS device is configured to retrieve mail for. Open the email message and touch the attachment to open it. You will be presented with
Open in OpenVPN as one of the available options. Touch the OpenVPN icon to select that option. The OpenVPN Connect App should then open and list the profile under a heading that says
New profiles are available.... Click on the green ball with the
+ sign in it to import the profile. Type in the username (admin) and password and change the On/Off switch to On.
The Android version of the OpenVPN Connect App allows you to import an OpenVPN profile from an SD card. Save the configuration file to the SD card. Launch the OpenVPN Connect App. From the menu, select Import, then Import Profile from SD card. Browse to the location of the configuration file and select it. Enter the username (admin) and password to connect to the VPN. Press Connect.
The TunnelBlick App for MacOS allows you to import an OpenVPN configuration file. Save the configuration to a file on your system. Click on
VPN Details. Click on the
+ symbol underneath the existing configurations to add a new configuration. Click on the
I have configuration files button. Click on the
OpenVPN Configuration(s) button. Follow the instructions presented by TunnelBlick (copy the config into an empty folder TunnelBlick creates on the Desktop, rename the folder, click on the folder). When the profile is imported successfully, click on it's name and then click on
Connect. Enter the username (admin) and password to connect to the VPN.
The OpenVPN Connect Client on Windows allows you to import an OpenVPN configuration file from the local disk. Save the file on your system. Click the
+ symbol to the right of
Connection Profiles. Select
Local File and click on the
Import button. Find the profile you wish to import in the file browser window and click
Open. A box with the name of the new profile should appear under
Connection Profiles now. Click on that box and enter the username (admin) and password to connect to the VPN.
An instance of the Netgate appliance can be used as a firewall for a VPC subnet. This will generally require more manual configuration than using an instance to host a remote access VPN does. See the VPC User Guide for a more detailed explanation of how to configure your VPC and your Netgate appliance instance to support this.
Amazon EC2 does not support native IPv6 connectivity. Thus, without additional manual configuration, it is not possible to send traffic to the IPv6 Internet from a client device through the VPN tunnel established with the Netgate pfSense certified firewall and VPN appliance instance. It should be possible to configure a tunnel between the instance and an IPv6 tunnel broker (Hurricane Electric, Sixxs, etc) manually. This configuration has not been tested and would be unsupported. A supported and automated IPv6 tunneling configuration may be available in a future release.
If your primary reason for using a VPN is to encrypt your traffic on wireless and untrusted networks, extra caution should be used when connected to a LAN that has support for IPv6 routing. Here's some more detail on the reasons...
During testing of different VPN configurations with the Netgate pfSense certified firewall and VPN appliance, it was noticed that some of the VPN clients tested were sending IPv6 traffic directly to the Internet outside of the VPN tunnel when the client was connected to a network that provided native IPv6 connectivity. This was observed with every IPsec client tested and some versions of OpenVPN clients. The reason for this behavior with IPsec clients is likely that the IPsec clients do not appear to have support for sending mixed IPv4 and IPv6 traffic over a single tunnel. So if an IPsec tunnel is established to a remote endpoint over IPv4, IPv4 traffic will be sent over the tunnel and IPv6 will not. If the tunnel is established over IPv6, the opposite behavior occurs. For OpenVPN tunnels sending mixed traffic is supported with some clients, but not all of them. Whether this works with a given client will depend on the particular implementation of the client, the platform and the version.
Many client apps, such as web browsers, use DNS to check whether a hostname has an IPv4 or IPv6 address, or both, associated with it. Once it is determined which IP address types exist, the app may make a decision on which address type to try to connect to. For example, it may attempt to connect to both simultaneously and proceed with whichever one succeeds first, or it may attempt to connect via IPv4 first and only attempt IPv6 if that fails, or it may attempt to connect via IPv6 first and only attempt IPv4 if that fails. In the case where a particular app decides to connect to an IPv6 host while connected to a VPN, it is likely that the IPv6 traffic will go direct to the Internet rather than through the tunnel.
The behavior of how an application decides which IP version to send traffic with and how the VPN clients manage routing of that traffic is dependent upon the behavior of the applications and the VPN clients on the devices. This behavior is under the control of the application and VPN client developers. There is little control over this available on the part of the VPN endpoint. For IPsec, no configuration is possible to eliminate this issue. For OpenVPN, the automatically configured OpenVPN remote access VPN attempts to push a configuration that will cause IPv6 traffic to be routed through the OpenVPN tunnel (ultimately traffic is blackholed and IPv6 is prevented from working, but it ensures that traffic is not being sent unencrypted directly to the Internet). Not all OpenVPN clients accept or properly utilize this configuration though, so it cannot be assumed to be an effective protective measure in every case.
Support for IPv6 routing is not currently likely to be present on most public LANs, so the risk presented by this situation may be tolerable to most users. Awareness of the potential for the issue to exist and caution when connecting to any network, especially where IPv6 is supported, are advised. If you want to determine whether IPv6 routing is supported on the network you are currently connected to, you could attempt to navigate to one of the popular sites available to test IPv6 connectivity, such as http://test-ipv6.com, while connected to the VPN. If the resulting test shows that you have IPv6 connectivity, that means your IPv6 traffic is being routed directly to the Internet. After determining whether this is the case, you can evaluate whether you wish to remain connected to the network.
In addition to connecting remote devices as clients, a device running pfSense as a firewall/router can be connected as a peer to a Netgate appliance. A pfSense document describing the process of configuring this setup resides here: http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_(Shared_Key,_2.0).
When implementing the configuration changes detailed in the document, you should use the Netgate appliance instance on AWS as the "server" end of the connection and your local pfSense device as the client "end". You will also need to make sure that you are using a unique port. The default remote access OpenVPN server is configured to use UDP port 1194. It is suggested that if you are adding a site-to-site tunnel, you should use a port between 1195 and 2000. Whichever port you decide to use, you will need to make sure that the port is open both in the firewall rules on the Netgate appliance instance and in the Security Group in the EC2 Management Console.
If you wish to route all traffic from your home/office network through the OpenVPN tunnel to your Netgate appliance instance, you will need to add this statement to the advanced options for the OpenVPN Client on the home/office pfSense device:
This will cause a default route to be set that sends all locally originated traffic on your home/office network over the OpenVPN tunnel when it is established. If you use this configuration to send all traffic from your local network through the OpenVPN tunnel, you will also need to establish a NAT on the Netgate appliance instance on AWS for traffic from the home/office network to the internet. This can be accomplished by adding the CIDR block for your home/office network to the preconfigured Alias called
Networks_to_NAT. This is done by navigating to
Aliases under the
Firewall heading on the web GUI, then clicking on the edit icon to the right of
Networks_to_NAT. Add the new network address and mask to the list of Networks and click the
Save button. Then click the
Apply Changes button. You will also need to add the network used for the tunnel endpoints (
IPv4 Tunnel Network) to the
Networks_to_NAT alias as well using the same procedure that was used to add the home/office network.
Multiple home/office networks can be connected to a single Netgate appliance instance. This could be used to allow clients at different office locations to communicate without requiring tunnels between each individual location. It could also be used as a way to apply policies on traffic to/from the internet in one place and have them take effect across multiple locations.
Each site would need to have the instructions above for connecting an individual device repeated to add an OpenVPN server on the Netgate appliance instance and an OpenVPN client on the local pfSense device. Each OpenVPN Server that is configured must use a unique port and a unique network for
IPv4 Tunnel Network. It is recommended to use a name that uniquely identifies each location connected in this manner in the Description field when adding an OpenVPN Server for a site in the Netgate appliance.