Why you may (likely do) need “Hairpin NAT” (NAT Reflection, NAT Loopback) for AIO/Nextcloud

[gork-us]

Hello all,

When Nextcloud AIO is set up, assumptions about networking and DNS resolution are made that come into play from the start of the installation, including the “domain check” process required to get AIO installed.

What is NAT?
Network Address Translation.
Many people use “RFC 1918” addresses on their private networks—these are specially reserved address ranges that cannot be routed on the Internet. For example, NAT allows many addresses to be “hidden” behind (originate from) a single address—it’s how you connect from your Internet provider to the Internet. It's also used for clients on the internet to access servers hosted on private networks, how you'll connect to your Nextcloud installation over the Internet.

The “typical” AIO setup:
In this example say your internal Nextcloud server IP is 192.168.1.100 (private).
You have a static (or dynamic) IP of 130.57.66.5 (public).
Your domain (DNS) name is “nextcloud.yourdomain.com”.

When someone on the Internet accesses “nextcloud. your domain.com,” DNS points them to 130.57.66.5, which is translated to 192.168.1.100 by your firewall and processed, returning as needed to the source. That’s NAT.

What is “Hairpin NAT”?
“Hairpin NAT” is causing a client to see a host’s external IP - from an internal network.

Why do you need to use “Hairpin NAT”? - Use Case 1
When your Nextcloud server at 192.168.1.100 resolves to “nextcloud.yourdomain.com” DNS resolves that name to130.57.66.5.

If 192.168.1.100 traffic is DNS going to google DNS server 8.8.8.8 it’s, from a firewall perspective:
192.168.1.100 (source) → 8.8.8.8 (destination) from 130.57.66.5 (NAT)
No problem there, normal NAT.

The AIO/Nextcloud domain check & Nextcloud office applications assume your server can talk to itself over it’s EXTERNAL (public) IP.
From a firewall perspective that’s not typical as the firewall sees the 192.168.1.100 traffic as locally connected.

The domain check function in AIO won’t accept RFC 1918 addresses so you can’t “fool” it by making 192.168.1.100 = “nextcloud.yourdomain.com”.

Solution?
You need to make 192.168.1.100 (the interface all of your docker containers access the Internet via - using NAT at the Linux Host/Docker level) see itself as 130.57.66.5.

In order to make this work your router/firewall must support “Hairpin NAT” and the creation of a “Virtual IP” (or VIP) - a virtual mapping of your internal server to an external address.

You will need to create a rule that is typically:
Source Network: LAN (192.168.1.0/24)
Destination Network: LAN (192.168.1.0/24)
Source: 192.168.1.100
Destination: “Virtual IP” of 192.168.1.100 (130.57.66.5)
Forwarding port: 443

This is in addition to the “default” policies:

Inbound: Allowing Internet traffic to your server (typically using the same “Virtual IP” - source all, destination VIP, port 443) as well as
Outbound: A generic “allow my host to the Internet” policy (from server private IP to destination all, port 80/443/53/25 or 587 - web, secure web, DNS, email)
This “Hairpin NAT” should allow the 192.168.1.100 server resolving “nextcloud.yourdomain.com” to 130.57.66.5 to trick the firewall into allowing your internal server to see itself using it’s external IP and port.

Yes, this means your firewall/router must support “Hairpin NAT” and you must have a port forward rule for each port you want to support inbound - 443 for SSL/HTTPS and 3478 if you are supporting a Talk server.

When “domaincheck” first runs it will see itself at 130.57.66.5 - the proper external (public) IP address for “nextcloud.yourdomain.com” and should be successful first time, every time.

This should also work for Office - which needs to see “nextcloud.yourdomain.com” in the Collabora server URL.

In both cases, this will work even if you are using a reverse proxy in front of AIO, or not.

Why do you need to use “Hairpin NAT”? - Use Case 2

Say you have an internal LAN that is 192.168.2.0/24 connected to your firewall/router.

Same process exists - resolve “nextcloud.yourdomain.com” to 130.57.66.5 and the router/firewall knows that 192.168.2.0 is a locally connected network and 130.57.66.5 = 192.168.1.100, on another locally connected network (perhaps a “DMZ” network).

If you are using DNS, even with your own server, “nextcloud.yourdomain.com” will resolve to 130.57.66.5.

While you could add your own DNS entries to make your 192.168.2.0/24 clients “see” “nextcloud.yourdomain.com” as 192.168.1.100 it’s additional configuration and if your nextcloud install is using your internal DNS can cause domaincheck to fail as it won’s support the 192 addresses in the check.

You need a way to make your internal clients “see” 192.168.1.100 as 130.57.66.5. How can you do that? Hairpin NAT again.

Create a rule as follows:
Source Network: LAN (192.168.2.0/24)
Desination Network: DMZ LAN (192.168.1.0/24)
Source: LAN (192.168.2.0/24)
Destination: “Virtual IP” of 192.168.1.100 (130.57.66.5)
Forwarding port: 443

This will allow your internal clients to resolve “nextcloud.yourdomain.com” to 130.57.66.5 without any DNS changes - and can also allow your nextcloud install, if using the same DNS, to be successfully installed.

If you have any questions please let me know.

[szaimen]

Hey, just added your wiki to the debug section: #5885