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

</aside>

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:

  1. 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
  2. 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 the source zone to that destination zone (If the translated destination is in DMZ, we would check for WAN to DMZ access rules alone)
  3. 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
  4. Taking the necessary action based on access rules - Perform allow, deny or discard action as per the access rule
  5. 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

<aside> 💡 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.

</aside>

==============================================================

<aside> 💡 Here are a few scenarios listed along with their troubleshooting steps:

</aside>

  1. Packets not reaching the firewall. Not all ports are always allowed inbound to the firewall from the upstream device. Especially 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.
  2. Packets are 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. The firewall 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.