In this article we will explain what is required for NAT when a device inside your network has issues connecting to UNMS when an FQDN is being used.
Table of Contents
Sometimes you may feel forced to rewrite the FQDN in your generic UNMS key with an IP address, in order to connect a device inside your network to UNMS. 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.
Setting the NAT
In the schema above, the domain
myunms.com is set up on 184.108.40.206 and there is a redirect on the gateway from 220.127.116.11:443 to 192.168.1.20:443. If the address
myunms.com is opened from the airMAX device it will not work.
The reason for that is that airMAX device asked DNS to translate
myunms.com and it received the public address 18.104.22.168. When the first packet is sent there the gateway router (EdgeRouter 4 in this example) it intercepts the packet and rewrites the destination IP to 192.168.1.20 (UNMS server). The UNMS server gets the packet and it replies with ACK packet (acknowledges the connection) which travels to a sender address - 22.214.171.124 (airMAX device). But the airMAX device sent a request to the 126.96.36.199 server and that server never answered, so that connection eventually times out. Instead, airMAX device receives 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 Source NAT all packets going to 192.168.1.20. Here is a guide how to setup source NAT on EdgeRouter devices. This technique is often called NAT Reflection/NAT Loopback/NAT Hairpinning.