Overview
In this article, we will explain what is required for NAT when a device inside your network has issues connecting to UISP when an FQDN is being used.
Table of Contents
Introduction
Sometimes you may feel forced to rewrite the FQDN in your generic UISP key with an IP address, in order to connect a device inside your network to UISP. In this situation, it is often useful to check if there is a correct source NAT set on your gateway. In this article, we will explain what is going on and how to fix the situation.
Network Diagram
Setting the NAT
In the schema above, the domain myuisp.com is set up on 203.0.113.1 and there is a redirect on the gateway from 203.0.113.1:443 to 192.168.1.20:443. If the address myuisp.com is opened from the airMAX device it will not work.
The reason for that is that the airMAX device asked DNS to translate myuisp.com and it received the public address 203.0.113.1. When the first packet is sent there the gateway router (EdgeRouter 4 in this example) intercepts the packet and rewrites the destination IP to 192.168.1.20 (UISP console). The UISP console (server) gets the packet and it replies with an ACK packet (acknowledges the connection) which travels to a sender address - 192.168.1.21 (airMAX device). But the airMAX device sent a request to the 203.0.113.1 server and that server never answered, so that connection eventually times out. Instead, the airMAX device receives an ACK packet from 192.168.1.20, which the airMAX device never tried to contact so that packet is discarded.
The solution to this issue is to add a rule to the gateway which will NAT all packets going to 192.168.1.20. Here is a guide on how to set up Hairpin NAT on the EdgeRouter.