Access (Beyond My) Control

Wow, thanks, man - that's a lot of output for a Friday night [;)]

Louis-M said:

Your DMZ is a physical network between the UTM and a Ubiquiti router. So for the flow going outwards, Traffic on the UTM leaves via the OUTSIDE (or external interface) on your UTM goes to the DMZ network. The DMZ network then goes to the Ubiquiti which in turn goes to the internet?

Yes.

On the inside...

My ESXi host has two physical interfaces in use at this time, both in a LAG. Both interfaces are assigned to vSwitch0. My ESXi has one VM port group labeled 4095 and configured with VLAN ID 4095. The VM vNICs are assigned the 4095 label, and the guest OS NICs are configured with the appropriate VLAN ID.

My old setup (TMG, virtualized) only had two vNICs at the VM, VLAN99 on one and VLAN65 on the other. All of the VLAN99 to VLAN100 routing was done with SVIs. It worked, and I don't recall doing anything other than creating a non-webserver publishing rule from External (aka VLAN65 aka DMZ) to the internal RDP host. I know it works, and I'd like to do it with my virtual UTM.

One reason I don't want to use a 3rd interface on my virtual UTM is that I often move truckloads of bits between VMs in VLAN100 and a physical NAS in VLAN99, and I can't help but think that hitting the it that hard would be a bad thing for the ESXi CPUs.

So today, VLAN100 routes out the UTM vNIC; then through the VM port group, vSwitch and vmNIC; down the LAG to the switch; and finally the SVIs kick it over to to the NAS LACP port group.

Does this flow make sense as opposed to introducing an additional hop through a second VM (the virtual UTM) on the way to the NAS?

Got it!

...although I will now need some help understanding WHY it works.

I went from using a DNAT to a Full NAT and set "change the source to External (WAN) (Address)".

Fired right up.

Why on earth....?

In general, Full NAT is used in two situations:

1. You have an internal server that is reached from the Internet and the FQDN for the server resolves to an IP on your External interface.  That won't work for accesses from "Internal (Network)" - a Full NAT that changes the Source to "Internal (Address)" is required.  The alternative to this is split DNS.
2. You have a VPN between site A and site B.  The FQDN to reach a server at site B resolves to an IP on the External interface at site A.  At site A, you need a Full NAT to send incoming traffic to the server at site B - again, the easy solution is to change the Source to the "Internal (Address)" at site A.  My preference, where possible, would be to use Webserver Protection in Site A instead of a NAT rule.

Your situation appears to be a variation of the VPN problem.  Since you control the IPs, you could have solved this with static routes, but I didn't take the time to understand the topology well enough to be able to give an example.

Cheers - Bob