Port Forward Troubleshooting

Port Forwards in particular can be tricky, since there are many things to go wrong, many of which could be in the client configuration and not AZTCO-FW. Most issues encountered by users have been solved by one or more of the following suggestions.

Port forward entry incorrect

Before any other troubleshooting task, verify the settings for the port forward.double check that the values are correct. Remember, if the NAT IP address or the ports are changed, the firewall rule may also need adjusting if a linked firewall rule was not chosen.

Common things to check for:

Correct interface: Usually WAN, or wherever traffic will enter the firewall.
Correct NAT IP: The IP address must be reachable from an interface on the firewall.
Correct port range: It must correspond to the service being forwarded.
Source and source port should almost always be set to any.

Missing or incorrect firewall rule

After checking the port forward settings, double check that the firewall rule has the proper settings. An incorrect firewall rule would also be apparent by viewing the firewall logs . Remember, the destination for the firewall rule is the internal IP address of the target system and not the address of the interface containing the port forward.

Firewall is enabled on the target machine

Another thing to consider is that AZTCO-FW may be forwarding the port properly, but a firewall on the target machine may be blocking the traffic. If there is a firewall on the target system, check its logs and settings to confirm whether or not the traffic is being blocked at that point.

AZTCO-FW is not the target system gateway

In order for AZTCO-FW to properly forward a port for a local system, AZTCO-FW must be the default gateway for the target system. If AZTCO-FW is not the gateway, the target system will attempt to send replies to port forward traffic out whatever system is the gateway, and then one of two things will happen: It will be dropped at that point since there would be no matching connection state on that router or it would have NAT applied by that router and then be dropped by the system originating the request since the reply is from a different IP address than the one to which the request was initially sent.

Target system has no gateway or cannot use AZTCO-FW as its gateway

A subset of the larger problem of the target machine gateway is when the device has no gateway, or is incapable of having a gateway. In these cases, work around that problem by switching to Hybrid or Manual Outbound NAT and crafting a rule on the LAN or other internal interface facing the local device. This rule would translate traffic from any source going to the target system on the target port.

For example, if there is a file server that does not support a gateway located at 10.3.0.6, switch to Hybrid Outbound NAT and create a rule like Figure at this picture to reach it from outside the network. The file server will see the LAN IP address of the firewall as the source of the traffic, and since that is “local” to the server, it will respond properly.

Fig. 5: Manual Outbound NAT Rule for LAN Device with Missing Gateway

Target machine is not listening on the forwarded port

If the request is rejected instead of timing out when the connection is tested, in all likelihood AZTCO-FW is forwarding the connection properly and the connection is rejected by the target system. This can happen when the target system has no service listening on the port in question, or if the port being forwarded does not match the port on which the target system is listening.

For example, if the target system is supposed to listen for SSH connections, but the port forward was entered for port 23 instead of 22, the request would most likely be rejected by the server. The difference can typically be detected by trying to connect to the port in question using netcat or telnet. A message such as “Connection refused” indicates something, frequently the inside host, is actively rejecting the connection. Using Diagnostics > Test Port can also help, see .

ISP is blocking the port

Some ISPs filter incoming traffic to well-known ports. Check the Terms of Service (ToS) from the ISP to see if there is a clause about running servers. Such restrictions are more common on residential connections than commercial connections. When in doubt, a call to the ISP may clear up the matter.

If ports are being filtered by the ISP, moving the services to a different port may work around the restriction. For example, if the ISP disallows servers on port 80, try 8080 or 18080.

Before attempting to work around a filter, consult the ISP ToS to ensure that running a server is not a violation of their rules.

Testing from inside the network instead of outside

By default, port forwards will only work when connections are made from outside of the local network. This is a very common mistake when testing port forwards.

If port forwards are not required to work internally. However, Split DNS is a more proper and elegant solution to this problem without needing to rely on NAT reflection or port forwards, and it would be worth the time to implement that instead.

Even with NAT reflection, testing from inside the network isn’t necessarily indicative of whether it will work from the Internet. ISP restrictions, restrictions on devices upstream from the firewall, amongst other possibilities are not possible to see when testing from within the network.

Incorrect or missing Virtual IP address

When using IP addresses that are not the actual IP addresses assigned to an interface, a Virtual IP address must be used (VIPs). If a port forward on an alternate IP address is not working, a different type of VIP may be required. For example, a Proxy ARP type may be necessary instead of an “Other” type VIP.

When testing, also make sure that the client is connecting to the proper VIP.

AZTCO-FW is not the border/edge router

In some scenarios AZTCO-FW is an internal router and there are other routers between it and the Internet also performing NAT. In such a case, a port forward must also be entered on the edge router forwarding the port to AZTCO-FW, which will then use another port forward to get it to the local system.

Forwarding ports to a system behind Captive Portal

Forwarding ports to a host behind a captive portal needs special consideration.