Introduction

As an employee of Adam Internet for the better part of a decade, I have been a customer of theirs, even for the the past three or so years since moving on.

Whilst they have been a consistently reliable provider for this time, it was time to move on. I had a less-than-standard residential service and it was only a matter of time before it was audited and brought to a standard service level.

Thus began my search for a new provider. I've now settled for TPG with their $59.99 a month unlimited ADSL2+ with home phone service. I'm not using the phone service, however, for less than what I was paying for internet before I'm now receiving a service with no cap on data.

In doing so, I'm now behind a single static IP address, where previously I had a routed /29 subnet (5 usable addresses). I've migrated most of the servers I had hosted locally to various providers as necessary, but still have a few services that remain local.

The need for NAT

As I'm now behind a single address, I have to be a bit more considered in my use of services and I don't want them globally accessible. Also, for some web-based utilities, remembering which port they all run on can be cumbersome - and my memory isn't great at the best of times.

I was previously using nginx as a proxy, however, that server was on one of those routed IP addresses, so was accessing services over the LAN. I'll continue using that setup, which I won't go into in this post.

Configuring NAT and firewall rules

I have a Ubiquiti EdgeRouter Lite - a terrific and simple to use yet powerful unit - so this post deals with specifics to that device. The theory would be similar in other devices.

Configure a destination NAT rule

From the Firewall/NAT tab, click on NAT, then the Add Destination NAT Rule button, which will present you the following dialogue.

On my inbound interface - pppoe0 - I configure the translation to the IP address of my local computer and relevant port.

Configure the relevant protocol and source address - the nginx proxy server, in this instance - and leave the source port blank. This will change from request to request.

Configure the destination address as your WAN address - in this instance, the static IP address assigned to me by TPG. The destination port will be the same as the translation port.

Click on Save for the Destination NAT Rule Configuration.

Configure firewall rule on WAN_IN ruleset

Click on Firewall Policies under the Firewall/NAT tab. By default, you will have a WAN_IN ruleset. Click on the Actions button, then on Edit Ruleset.

On the modal that opens, click on Add New Rule, where you will be presented with the following dialogue:

The action should be set to Accept and the protocol will match what was specified when configuring the destination NAT rule; TCP in this instance.

Click on the Source tab. In the Address field, enter the same IP address you entered in the Src Address field of the destination NAT rule configuration dialogue:

Lastly, click on the Destination tab, and enter the Address and Port matching those in the translation section of the destination NAT rule configuration dialogue:

Click on Save then close the Rule Configuration dialogue. The next step is important, and that is to make sure that your allow rules are placed higher than the default Drop invalid state rule. This should always be the last rule in your ruleset. Simply click and drag the rule above, then click Save Rule Order.

Conclusion

That's all there is to it. It took me a bit of messing around with the rules to figure out what was expected in each of the fields - especially when identifying whether the WAN IP or the local server's address was the source or destination address.

This will narrow the number of external computers and networks getting at those services on your network, by limiting the port forwarding rules to only those you specify in your WAN_IN ruleset. As NAT rules are carried out before firewall rules are applied, you need to perform the translation, then allow through the firewall on the rewritten rule.

The alternative to this, of course, is to add a simple Port Forwarding rule. The caveat to this approach - and the reason I decided against it - is that it expose those ports and subsequently the services behind them to the entire public internet.