This is my first attempt to configure a NAT rule. Even though the documentation is relatively clear, it does not contain WebFig examples. Such examples would be very useful.
When configuring a NAT rule (for example passing SSH to a specific LAN host), I configure the src and dst ports to 22, the protocol to TCP, the src address to my exposed static IP, and the dst address to the LAN address of my destination machine (192.168.x.y). Need I configure any other setting?
Once the NAT rule is in place, do I need to configure a firewall rule too?
The documentation suggests that I need to clear the connection tracking tables to ensure that the rule(s) function. How does one do this?
Is there a way to filter the connection table to see whether requests from the internet are being handled by my NAT/rule?
You should not be matching on src-port for a port forward. The host initiating the connection to your SSH server will be sourcing their side of the connection from a random TCP port, not from 22. Only the DESTINATION port is guaranteed to be 22. So one reason that your port forward rule is failing to get hit is because no outside connection is matching it, due to specifying src-port=22 in the rule.
This is also incorrect. What may not have been exactly clear to you is that every parameter on every tab EXCEPT for the “Action” tab is a matcher. Meaning, they check for conditions; they don’t make changes. The rule will only be triggered IF all of the conditions specified by all of the matchers you have configured happen to be true. The more matchers you set, the more specific the conditions will need to be to trigger the rule. If the rule is triggered, THEN the action specified on the “Action” tab will be taken. It is the parameters on that tab (and that tab only) that actually affect any kind of change.
At the point that an unsolicited connection request to TCP port 22 comes into your router from the outside, “src-address” is the IP of the host making the SSH connection attempt to your server, and “dst-address” is your router’s WAN IP. So if you want the rule to trigger when a packet comes into your router where the destination address is your WAN address, and where the protocol is TCP, and where the destination TCP port is 22, then you would set dst-address=, protocol=tcp, dst-port=22, and leave all other matchers not set to anything.
You didn’t explicitly mention it, but just in case: chain for a port forward rule like this should be “dstnat”, because you are going to be using this rule to re-write the destination address in the incoming packet, while leaving the source address intact.
Then, on the Action tab, you specify an action of “dst-nat”, and then set to-addresses to your server’s INTERNAL IP address (192.168.x.y). It’s the to-address setting that specifies what the source (if action=src-nat) or destination (if action=dst-nat) should get changed to.
Just to amend: if your WAN IP address is not truly static (as in: set manually under IP → address) and the rest of router setup is (more or less) default, then instead of using “dst-address” matcher it’s often better to use “in-interface-list=WAN” matcher. Using “in-interface-list” or “in-interface” matchers does come with problems in certain use cases (look for description of “hairpin NAT”).
It is pretty essential to use one of “dst-address” or “in-interface-list” or “in-interface” matchers so that NAT rule doesn’t “catch” SSH connection initiated inside LAN (and targeting internet destinations).
Yes, indeed. The OP did talk about his “exposed static IP”, though, and since it was clear that there was still not yet a clear and settled understanding of ROS firewall/NAT rules established even after having read the docs, I was mostly trying to explain how to correctly write the exact same specific rule he was describing himself attempting to create, without confusing the issue further by adding a bunch of other details. I find that once the core principles to something are finally understood, then it is much easier to dive deeper and start layering on other concepts, such as actual best practices, especially since the “whys” behind those best practices actually make sense once you finally understand how the machine under-the-hood actually works.