This article describes how to configure port forwards on a UniFi Security Gateway, and how to troubleshoot them if not working as desired.
Port forwards allow you to redirect traffic destined to one or more ports on your USG’s WAN IP to an internal host, most commonly to make servers accessible from the Internet.
Table of Contents
- Port Forwarding Configuration
- Example Network Overview
- Opening the Port Forward Tab
- Port Forwarding Configuration Fields
- Example Web Server Port Forward
- Example SSH Port Forward
- Port Forward List View
- Port Forwards and Firewall Rules
- Port Forward Troubleshooting
- Verify Configuration and Test Methodology
- Check for traffic on WAN
- Check for traffic on LAN
- Traffic not reaching WAN
- No reply from LAN host
- Related Articles
|Port Forwarding Configuration|
Example Network Overview
Before you begin, and to make these examples easier to follow, please note that the network depicted in the examples has a USG with WAN plugged into an Internet connection with IP of 192.0.2.117, and LAN with an IP of 172.16.0.1 plugged into a UniFi switch. On the LAN there is a Linux server at 172.16.0.7, which is running web and SSH servers.
Opening the Port Forward Tab
UniFi Security Gateway (USG) port forwards are configured in the device’s Properties panel in the UniFi Controller. To get there, follow these steps:
- Click Devices on the left-hand side menu
- Select your USG by clicking on it.
- The Properties panel will appear on the right-hand side of your screen, open on the Details tab. Click on Configuration
- Click on Port Forward to expand. You’ll start with no port forwards configured, as shown below.
- Click Create to configure your first port forward.
Port Forwarding Configuration Fields
The following fields are available for configuration in port forwards:
Name: Descriptive name of the port forward for reference purposes only. No functional impact.
From: This field specifies the source addresses that are allowed through the port forward. If you need the service to be reachable from anywhere on the Internet, you must select “Anywhere” here. In cases where you can limit the source IP or network that can use the port forward, it is best to do so, as it greatly limits the security exposure of your network. To restrict source IPs allowed through the port forward, select “Limited”, and in the text box to its right, enter an IP address (e.g. 198.51.100.123) or IP subnet with CIDR mask (e.g. 100.70.60.0/24). Only the specified IP or network will be allowed through the port forward.
Note: If you need to permit multiple source IP addresses or subnets, you can add multiple port forwards, with a different “From” IP or subnet on each.
Port: The Port field specifies the external port to be forwarded. This port on your WAN IP will be forwarded.
Forward IP: This field specifies the internal IP address to use for the destination of this port forward.
Forward Port: The Forward Port specifies the internal port to where the traffic is forwarded.
Protocol: Here you can select TCP, UDP or Both (TCP and UDP) as the protocol forwarded. Most services use TCP. Unless both TCP and UDP are required, you should specify one or the other rather than Both.
Example Web Server Port Forward
Now that you are familiar with each field in the Port Forward tab, let’s create some sample Port Forwards. For the first example, we’re opening HTTP (TCP port 80) to the Linux server at 172.16.0.7.
Click Apply after filling in the fields appropriately. The configuration will provision to the USG, and the port forward will be active once provisioning has completed. Make sure to test your port forwards from outside your network on the Internet.
Example SSH Port Forward
For this example, we’ll forward external port 2222 to the Linux server’s SSH on port 22. SSH is a common example of a service that people often configure externally on a different port than internally, mostly to avoid the bulk of brute force attacks. There is no real security in doing so, as any system susceptible to a SSH brute force attack will be found and compromised regardless of port, but there is value in considerably reducing log spam from authentication failures, and not wasting system resources on processing the attempts. It’s preferable to limit source IPs or networks on such forwarded traffic, but if you have a requirement to leave SSH open to the Internet, using an alternate external port doesn’t hurt.
Once again, click on Apply. Once provisioning of the USG is complete, the Linux server’s SSH service will be reachable from the Internet on 192.0.2.117 port 2222.
Port Forward List View
Now the Port Forwards panel would display two configured entries:
You can click the pencil to the right of an entry to edit it, or the trashcan to delete.
Note: If the edit and delete buttons are not visible, look at the scroll bar at the bottom of the port forward panel, directly underneath “Showing X-Y of Z records.” Scroll to the right to find the edit and delete buttons.
Port Forwards and Firewall Rules
In the WAN IN firewall rules displayed in the controller, you will see rules added to pass the traffic associated with your port forwards.
These rules are not editable because they’re associated with the port forwards, and their configuration specifics all come from the port forwards. You edit or delete the port forwards to edit or delete those rules.
|Port Forward Troubleshooting|
There are a number of potential reasons for port forwards not working after they’re configured, most all of which are outside of USG itself, but USG provides powerful tools to help pinpoint the cause of the problem.
This section goes through the troubleshooting process when your port forwards aren’t working as expected.
Verify Configuration and Test Methodology
First, take a close look at your configured port forwards. A subtle typo in an IP or port number has tripped up all of us on occasion. The UniFi controller won’t allow invalid characters, so no need to look closely for white spaces or anything along those lines. Just verify the IP and port is correctly entered.
When testing your port forwards, make sure to do so from the Internet. A cell phone with wifi disabled is a good option if nothing else is readily available.
The next sections go through the process of troubleshooting from the WAN and LAN points of reference.
Check for traffic on WAN
The first step in troubleshooting port forwards is ensuring the traffic is reaching your WAN interface. If the traffic isn’t reaching USG’s WAN, it can’t be forwarded. Packet capturing with tcpdump is the preferred method of troubleshooting, as seeing the traffic present or not present on the network definitively determines where the problem exists. The WAN interface on USG is eth0, and eth2 on USG Pro. The examples in this article refer to a USG, so we will use eth0. If you’re using a USG Pro, substitute it for eth2.
Without some filtering, the output of tcpdump will be difficult to decipher. A simple filter for destination port often suffices, though if it’s a port shared by other active traffic on the network, that alone is inadequate. The HTTP port forward for instance requires tighter filtering to eliminate unrelated noise. In our use case here, we will filter on destination host 192.0.2.117 (the USG WAN IP) and destination port 80 using the filter dst host 192.0.2.117 and dst port 80.
SSH into the USG to start. Then run the following tcpdump to look for the incoming HTTP requests:
sudo tcpdump -ni eth0 dst host 192.0.2.117 and dst port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:44:00.904533 IP 198.51.100.114.51514 > 192.0.2.117.80: Flags [S], seq 2179876751, win 29200, options [mss 1460,sackOK,TS val 390060839 ecr 0,nop,wscale 6], length 0
That shows a connection attempt to port 80 on USG’s 192.0.2.117 WAN IP, sourced from a remote host on the Internet with IP 198.51.100.114, using source port 51514 (source ports are random from the ephemeral port range). The “Flags [S]” part tells us it’s a SYN packet, the first packet of an attempted TCP handshake. Because we see this request on the WAN, we know it’s reaching USG. If nothing were to show up in that capture while attempting to reach http://192.0.2.117, then we know something upstream of USG is preventing the traffic from reaching it. See the “Traffic not reaching WAN” section below for troubleshooting guidance.
If you do see traffic coming into WAN, then next is to verify whether it’s leaving LAN.
Check for traffic on LAN
Now that you have verified the traffic is arriving on WAN, your next step would be to check LAN to see if the traffic is egressing the LAN interface. In this example we’re using a USG, where the LAN port is eth1. If using USG Pro, the LAN port is eth0, so substitute accordingly in tcpdump.
Here we will filter on the web server’s internal IP and port 80:
cmb@usg1:~$ sudo tcpdump -ni eth1 host 172.16.0.7 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
18:00:38.268095 IP 198.51.100.114.51519 > 172.16.0.7.80: Flags [S], seq 1565978093, win 29200, options [mss 1460,sackOK,TS val 390310233 ecr 0,nop,wscale 6], length 0
18:00:38.268351 IP 172.16.0.7.80 > 198.51.100.114.51519: Flags [R.], seq 0, ack 1565978094, win 0, length 0
We see the SYN just like in the WAN capture. Here we see its destination IP has been translated to the internal server IP 172.16.0.7. Seeing the presence of that translated SYN leaving the LAN NIC means the port forward is working. The packet shown in response, coming back from the server, points to what the problem is in this case. Flags [R.] means the server sent a RST ACK in response, which is TCP’s way of telling a remote host there is nothing listening on that port. After checking the web server, the nginx service wasn’t configured to start. After starting the web server service, the tcpdump output shows several more packets in the exchange. A successful connection will look something along the lines of the following, with variance on how many lines are shown depending on the amount of data transferred:
18:06:17.151027 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [S], seq 4065224865, win 29200, options [mss 1460,sackOK,TS val 390394972 ecr 0,nop,wscale 6], length 0
18:06:17.151269 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [S.], seq 2746330992, ack 4065224866, win 28960, options [mss 1460,sackOK,TS val 232937488 ecr 390394972,nop,wscale 7], length 0
18:06:17.152707 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [.], ack 1, win 457, options [nop,nop,TS val 390394972 ecr 232937488], length 0
18:06:17.155836 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [.], ack 110, win 227, options [nop,nop,TS val 232937488 ecr 390394973], length 0
18:06:17.157676 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [F.], seq 110, ack 1105, win 491, options [nop,nop,TS val 390394974 ecr 232937488], length 0
18:06:17.157904 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [F.], seq 1105, ack 111, win 227, options [nop,nop,TS val 232937488 ecr 390394974], length 0
The most common failure is the LAN host not replying to the forwarded traffic. Where the tcpdump output shows SYNs being sent out to the LAN host, but nothing coming back in response, the issue is something on the LAN host itself. See No reply from LAN host below for troubleshooting guidance. The tcpdump output will look similar to the following:
xxx18:09:46.403313 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390447296 ecr 0,nop,wscale 6], length 0
18:09:47.400988 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390447546 ecr 0,nop,wscale 6], length 0
18:09:49.403930 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390448047 ecr 0,nop,wscale 6], length 0
Traffic not reaching WAN
If the traffic isn’t showing up on your USG WAN interface, something upstream of the USG is blocking it. Often this is a firewall or other packet filter of sorts built into your modem, or on some other upstream firewall or router. Refer to your modem’s manual to find out more about its configuration in that regard.
The other common circumstance is your ISP blocking the port you’re trying to use. Business class Internet service generally does not have any ports blocked, however it’s relatively common for residential service to have the ports of common servers (25, 80, 443, etc.) blocked.
No reply from LAN host
When you see traffic leaving LAN going to the appropriate destination host like shown in the final tcpdump output shown above, with three SYNs in a row sent to 172.16.0.7 port 80, the host isn’t replying to the traffic for some reason. Often this is a host firewall blocking the traffic on that system. The other common cause is the LAN host missing a default gateway, or having its default gateway configured pointing to a different system. In order to reply back via USG to make the port forwards work, the LAN host’s default gateway must point to USG’s internal IP.