ME - MER ELECTRÓNICA Universidad Laboral de Albacete

EdgeMAX - PortForward

This article describes the "traditional" way of setting up forwarding using destination NAT and firewall. As of version 1.4.0 there is port-forward wizard in the GUI that greatly simplifies basic port-forwarding. The wizard only handles the primary address on 1 WAN interface, so if you're doing something more complicated than that, you'll still need the "traditional" way.

This article is an example of port forwarding so that a host on Internet can get to a server on your private network. We want to be able to ssh using port 2222 to go from host H1 on Internet to port 22 on server A. Because server A is on a private network we'll need to create a port forwarding (or destination NAT) rule.

Table of Contents

  1. Network Diagram
  2. Port Forward
  3. Testing
  4. Firewall
  5. Testing Firewall

Network Diagram

In this example we'll be using the following address:

  1. WAN eth0
  2. LAN eth1
  3. Server A

We'll assume there's already a masquerade rule in place so that the hosts on the LAN can communicate with hosts on Internet. That rule would look like:

Port Forward

Now for the port forwarding rule we'll click on Add Destination NAT Rule and for the destination address we'll use the public address of the router with port 2222. For the translation we'll use the private address of server A and port 22.

Note: logging was also enabled to have a record of every outside address that does an ssh to server A.


For this lab test my host H1 and server A also happen to be EdgeRouter LITEs:

On the router R1 we can verify that the port forwarding worked by using "show nat translations" which will show the active translations:

Since I enabled logging on this NAT rule, I can also use "show log" to look for the message:


Destination NAT and firewall can be a bit confusing, so in my opinion it's easier to debug NAT and Firewall separately. So in the example above I had temporarily disabled my firewall (this works fine in a lab setting, but you would do that on a production router). Now I'll re-enable my basic firewall which looks like this:


Testing Firewall

Since I have enable-default-log on my WAN_IN rule set, I'll just try the ssh again and see what gets dropped.

First I see that logging of the NAT translation:

Testing Firewall

Right below that I see the following log for a drop on the default-drop:

This is one of the most common firewall mistakes with destination NAT - the translation happens before the firewall rules, so your rules need to allow instead of We can see this from the feature ordering chart at EdgeOS Feature Ordering.

So lets add our firewall rule to allow tcp port 22:

Now we try it and it works again and if we look at the Stats tab on the firewall we can see that rule 3 has been hit.