Common mistakes with port forwarding

11/28/2023 594 People found this article helpful 478,643 Views

Description

This article lists some of the common mistakes done while creating port forwarding rules and troubleshooting steps that can be taken.

Resolution

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

The firewall checks for the service and determines whether it is used by itself first on the WAN interface IP. Eg: HTTP/HTTPS management (TCP 80 and 443 respectively), SSH management (TCP 22), IKE (UDP 500), SSLVPN (TCP 4433). If not, the following series of events take place:

NAT policy lookup - We go through the list of NAT policies based on source IP, destination IP, service and inbound interface and stop after the first match based on priority
Determining the destination zone based on the NAT lookup - After it finds a match it checks the zone of the translated destination to find the access rules to match from source zone to that destination zone (If the translated destination is in DMZ, we would check for WAN to DMZ access rules alone)
Checking the necessary access rules - Go through the list of access rules based on priority and stop once a match is found ignoring all subsequent rules
Taking the necessary action based on access rules - Perform allow, deny or discard action as per the access rule
NAT policy action - If the packet is supposed to be allowed, we change the source IP, destination IP and service fields as described by the NAT policy

EXAMPLE: Let us consider that we are trying to forward Terminal Services (TCP/UDP 3389) to internal IP 192.168.168.68 on LAN and we would like to RDP using the WAN address X1.

NOTE: Usually the X1 IP on the firewall is a public IP and because of this we have blurred it.

Please take a look at How Can I Enable Port Forwarding And Allow Access To A Server Through The SonicWall? for the necessary steps needed for port forwarding.

Mistakes in Access rules:

Using the private IP instead of public IP in the destination field.

Since the access rule action takes before the NAT policy action, the match is always done against the original source, destination and services fields. Rule of thumb is that original source, destination and service fields in the inbound NAT should be used in the access rule.
Setting the source port to same as service

Every connection is made by using a random source port which is decided by the host machine trying to make that connection. Therefore, the source port field on access rule should always be left at Any.
Incorrect destination zone
Since we only check a specific set of access rules after determining the destination zone, it is essential to create the access rules between the right zones. WAN to LAN access rules will not be checked if the translated destination field resides in DMZ.
Not setting the right priority

Access rules and NAT policy are both checked based on priority. An incorrect NAT/access rule with higher priority will make the SonicWall not even check the right rules added just because they are on low priority. Always use the most specific rules with higher priority.

Mistakes in NAT policy:

Setting the translated service to same as original source

When no translation is required for the service it is essential to leave it on Original. Translated service should only be used during PAT. This creates a problem especially when a service group is used in the service fields.
Setting no/incorrect inbound interface.

Adding an inbound interface for inbound NAT sets the right priority and triggers this rule when traffic reaches the firewall on the right interface. Leaving it on Any can create issues when you have multiple WAN interfaces and you are configuring multiple NATs based on the available public IPs on each of those interfaces. Incorrect inbound interfaces will make the firewall completely overlook this NAT.

TIP: Always test the port forwarding internally using the internal IP first. If that does not work, it will not work from outside the network as well.

With all the above-taken care of, there might be still situations where the port forwarding is failing. The best way to troubleshoot port forwarding will be doing a packet capture. For more details on Packet monitor tool, please check How Can I Setup And Utilize The Packet Monitor Feature For Troubleshooting?

Always use the following method for packet capture as it would show the translated packets and make it easier to find the root cause. Use the source IP field with the source IP you are testing from. This shows you the translated destination and service after the firewall performs the NAT.

Working scenario:

Here are a few scenarios listed along with their troubleshooting steps:

Packets not reaching the firewall
Not all ports are always allowed inbound to the firewall from the upstream device. Specially if you are dealing with random custom ports please verify with your ISP to make sure that they are allowing those ports till the firewall. Without the traffic reaching the firewall, it cannot take any action on it.
Packets being dropped as Policy drop

This could take place due to multiple reasons.
a) The access rules are created between incorrect zones
b) The source port is set to something specific in the access rule
c) The translated destination belongs to the L2TP IP pool. SonicWall binds the L2TP IP pool to the zone VPN irrespective of whether that IP is being used by an L2TP client or not. Make sure that this pool is always set to a reserved pool which is not used anywhere else.
The packets are reaching the firewall but stay in consumed/received status

a) Please check the Network | System | ARP table and make sure that you can see the ARP entry for the internal device that you are trying to reach
b) You can try a ping test from the firewall from Device| Diagnostics and use the Ping tool from Diagnostics tools
c) Also check the Policy | Rules and policies| Routing rules section to make sure that there are no incorrect routes added for that destination IP
Packets are being allowed but there is no response

a) Make sure that the translated destination is the right private address. If not, please check the priority of the NAT policy
b) If the translated destination is correct, make sure that there is no Windows firewall or 3rd party AV that could be blocking this traffic. Another reason could be a different gateway on the end machine due to which the response could be going to a totally different device rather than reaching the firewall.
Packets are being allowed but the internal machine sends an ACK+RST, we can see this if we click on the dropdown of the packet in the Packet monitor

This usually takes place if the service is not running on that machine or it is running on a different port.
You can use the following command on the command prompt for a Windows device to see if the required ports are open on the internal machine. It shows a listening state for the ports that are open
netstat -an

For a specific port number, you can use the command below. Replace 3389 with the desired port number.
netstat –an 1 | find “3389”

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

Firewall checks for the service and determines whether it is used by itself first on the WAN interface IP. Eg: HTTP/HTTPS management (TCP 80 and 443 respectively), SSH management (TCP 22), IKE (UDP 500), SSLVPN (TCP 4433). If not, the following series of events take place:

NAT policy lookup - We go through the list of NAT policies based on source IP, destination IP, service and inbound interface and stop after the first match based on priority
Determining the destination zone based on the NAT lookup - After it finds a match it checks the zone of the translated destination to find the access rules to match from source zone to that destination zone (If the translated destination is in DMZ, we would check for WAN to DMZ access rules alone)
Checking the necessary access rules - Go through the list of access rules based on priority and stop once a match is found ignoring all subsequent rules
Taking the necessary action based on access rules - Perform allow, deny or discard action as per the access rule
NAT policy action - If the packet is supposed to be allowed, we change the source IP, destination IP and service fields as described by the NAT policy

EXAMPLE: Let us consider that we are trying to forward Terminal Services (TCP/UDP 3389) to internal IP 192.168.168.68 on LAN and we would like to RDP using the WAN address X1 IP-192.168.188.200

NOTE: Usually the X1 IP on the firewall is a public IP and is directly accessible from the internet. Taking a private IP as an example.

Please take a look at How Can I Enable Port Forwarding And Allow Access To A Server Through The SonicWall? for the necessary steps needed for port forwarding.

Mistakes in Access rules:

Using the private IP instead of public IP in the destination field.

Since the access rule action takes before the NAT policy action, the match is always done against the original source, destination and services fields. Rule of thumb is that original source, destination and service fields in the inbound NAT should be used in the access rule.
Setting the source port to same as service

Every connection is made by using a random source port which is decided by the host machine trying to make that connection. Therefore, the source port field on access rule should always be left at Any.
Incorrect destination zone
Since we only check a specific set of access rules after determining the destination zone, it is essential to create the access rules between the right zones. WAN to LAN access rules will not be checked if the translated destination field resides in DMZ.
Not setting the right priority

Access rules and NAT policy are both checked based on priority. An incorrect NAT/access rule with higher priority will make the SonicWall not even check the right rules added just because they are on low priority. Always use the most specific rules with higher priority.

Mistakes in NAT policy:

Setting the translated service to same as original source

When no translation is required for the service it is essential to leave it on Original. Translated service should only be used during PAT. This creates a problem especially when a service group is used in the service fields.
Setting no/incorrect inbound interface.

Adding inbound interface for inbound NAT sets the right priority and triggers this rule when traffic reaches the firewall on the right interface. Leaving it on Any can create issues when you have multiple WAN interfaces and you are configuring multiple NATs based on the available public IPs on each of those interfaces. Incorrect inbound interfaces will make the firewall completely overlook this NAT.

TIP: Always test the port forwarding internally using the internal IP first. If that does not work, it will not work from outside the network as well.

With all the above taken care of, there might be still situations where the port forwarding is failing. The best way to troubleshoot port forwarding will be doing a packet capture. For more details on Packet monitor tool, please check How Can I Setup And Utilize The Packet Monitor Feature For Troubleshooting?

Always use the following method for packet capture as it would show the translated packets and makes it easier to find the root cause. Use the source IP field with the source IP you are testing from. This shows you the translated destination and service after the firewall performs the NAT.

Working scenario:

Here are few scenarios listed along with their troubleshooting steps:

Packets not reaching the firewall
Not all ports are always allowed inbound to the firewall from the upstream device. Specially if you are dealing with random custom ports please verify with your ISP to make sure that they are allowing those ports till the firewall. Without the traffic reaching the firewall, it cannot take any action on it.
Packets being dropped as Policy drop

This could take place due to multiple reasons.
a) The access rules are created between incorrect zones
b) The source port is set to something specific in the access rule
c) The translated destination belongs to the L2TP IP pool. SonicWall binds the L2TP IP pool to the zone VPN irrespective of whether that IP is being used by an L2TP client or not. Make sure that this pool is always set to a reserved pool which is not used anywhere else.
The packets are reaching the firewall but stay in consumed/received status

a) Please check the MANAGE | Network | ARP table and make sure that you can see the ARP entry for the internal device that you are trying to reach
b) You can try a ping test from the firewall from INVESTIGATE | System Diagnostics and use the ping tool from Diagnostics tools
c) Also check the MANAGE | Network | Routing section to make sure that there are no incorrect routes added for that destination IP
Packets are being allowed but there is no response

a) Make sure that the translated destination is the right private address. If not, please check the priority of the NAT policy
b) If the translated destination is correct, make sure that there is no windows firewall or 3rd party AV that could be blocking this traffic. Another reason could be a different gateway on the end machine due to which the response could be going to a totally different device rather than reaching the firewall.
Packets are being allowed but the internal machine sends an ACK+RST

This usually takes place if the service is not running on that machine or it is running on a different port.
You can use the following command on the command prompt for a Windows device to see if the required ports are open on the internal machine. It shows a listening state for the ports that are open
netstat -an
For a specific port number, you can use the command below. Replace 3389 with the desired port number.
netstat –an 1 | find “3389”