I’ve read through the connectivity section in the docs and all it says is that the rack controllers need to be able to communicate with the region controller(s). It doesn’t mention anything about what connectivity the region controllers need (if any) back to the racks.
Refer to diagram below.
Behind City A’s Internet Address I have an internal network segment. All outbound traffic from this segment gets NAT’d and hidden behind City A’s ‘Internet address’.
I can get out to the internet and to the region controller from here no problem.
I’ve allowed all traffic from City A to the region controller on the firewall in City B.
I’ve successfully registered and synced the rack controller using:
maas-rack register --url http://maas.some.where:5240/MAAS --secret supers3cr3tk3ylol
What I’m seeing though is when a new machine goes through enlistment, it sits in commissioning state and doesn’t transition to new on the MAAS dashboard even though it’s already turned off
Ha! The inner workings of MAAS is actually pretty glamorous.
Played with this a bit more, and it looks like commissioning is failing because the node gets a 403 forbidden on the MAAS Proxy.
The list of authorised networks in /var/lib/maas/maas-proxy.conf is maintained and updated from the discovered and declared networks. The Public IP of City A is completely foreign to MAAS
So I guess this won’t work 
As long as the rack controller can communicate with the region controller, then that network topology should work just fine because starting from 2.5+ all traffic to MAAS should be proxied via the rack controller (from the machines). That traffic is access to metadata server, proxy, ntp, dns, etc.
@andreserl so while I agree with your statement of one way communication from the racks to region, in a NAT scenario this doesn’t work.
What I did was add the public IP address of City A to the fabric belonging to the rack controller. This allowed the proxy bits to start working, but when ‘deploying’ a machine the deploy would soft fail, where it never completes and the machine undergoing deployment ends up in a fail reboot loop, never notifying the region of the failure.
