Access (Beyond My) Control

Nice, post, Timothy - welcome to the UTM Community!

Does #1 in Rulz provide any insights?

Cheers - Bob

Thanks, Bob! You are an impressive member of this community and I appreciate your assistance.

I don't think I've violated any of the rulz.

Rule #1 - I see a white row in the firewall log when this happens, showing a good connection for the DNAT. IPS and ATP are disabled. New user, new install, baby steps.

Rule #3 - check. Although perhaps later on, after things are stable, I'll experiment with these settings --- mostly for the same reason a kid has to touch a hot stove to learn about being burned ;)

Rule #3.1 - Devices in my LAN have varying gateways depending on their VLAN. Do my notes in the first post make sense? ...and then please tell me if I did the right thing.

Rule #4 - check.

Rule #5 - check.

I forgot to include in the OP that the pfirewall.log on the RDP host does not show any evidence that the DMZ client has tried to connect to it.

I need to hack on this some more but I was up VERY late last night learning a difficult lesson with forcing DNS via recursive lookups from my AD DCs to my UTM to a DNAT on my EdgeRouter Lite, and the way the ERL writes the ISP DNS name servers into resolv.conf when the external interface is configured by DHCP, effectively bypassing the DNAT. Wow. Hours of sleep lost in the name of a lab education ;)

Thank you, sachingurung. I made a capture using this command line ...

tcpdump -i eth1.65 src 192.168.65.113 -w /var/log/rdpdump.sniff

...and put the resulting file here for your review.

I've got a lot to learn about reading capture files, I hope something is immediately apparent to you.

Maybe barking up the wrong tree, but ..... I saw the field "Source GeoIP: Unknown". I do indeed have country blocking enabled, allowing only US and Canada. After seeing that field, I created and enabled a Country Blocking Exception List for All Countries from External (WAN) (Network) using Microsoft Remote Desktop (RDP). The exception list made no difference, so I disabled Country Blocking altogether, again no difference. Currently I have Country Blocking enabled and the exception list disabled.

Firewall log entry from that attempted session:

2016:09:23-08:59:48 utm-tcs01 ulogd[4540]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62001" initf="eth1.65" srcmac="00:16:cf:85:a6:8c" dstmac="00:0c:29:ed:a8:fc" srcip="192.168.65.113" dstip="192.168.65.253" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="60189" dstport="3389" tcpflags="SYN"

Thanks ;)

On your diagram:

Is point 1 to point 2 a trunk port carrying both vlan 99 and vlan 100 to the same physical interface on the UTM?

OR

Is it 2 physical cables (from each vlan) going to 2 physical interfaces on the UTM?

A physical diagram is beyond my capabilities at this time. I'm not a network engineer, I just pretend to be one sometimes. ;)

Let's see if I can describe.

One of the SSIDs sets the DHCP addressing for the DMZ and points the client's gateway toward the internal interface of the EdgeRouter Lite (Point4 in my OP), then it tags outbound wired packets with VLAN65 and sends them down a trunk to an upstream POE switch not shown here, where they meet up with packets from several client ports also tagged VLAN65. All of those VLAN65 packets ride a trunk (along with some other VLANs) to the "core" switch represented by Point1 in my OP, where they drain out another VLAN65 tagged port to the internal interface of the EdgeRouter Lite (again, Point4 in my OP).

Would it be correct for me to say that the packets are making their way to the UTM, it just doesn't know what to do with them?

Sorry, there's still too much info there for me to grasp.

From the left side (point 1 = Your switch)   ...... is it just the one physical cable going to the UTM?

What I'm trying to find out is if the vlans are using a trunk or if each vlan has it's own cable connected to a seperate interface on the UTM.

This will make a difference on how the interfaces are set up on the UTM ie either ethernet or ethernet vlan

We can then go from there to the next stage

Thanks again. I don't talk "network" very well, just enough to get myself in over my head, but I'll attempt it....

The switch at Point1 is serving as a core/access switch with default VLAN1. Most of the devices in this scenario are directly connected to it, with the exception of the wireless devices in VLAN65, which come into the core switch via a trunk from the upstream distribution/access POE switch and the WAPs connected to it.

My UTM is a VM on an ESXi 5.5 host. The host physical network interface is a trunk of VLAN65, VLAN 99 and VLAN100. My UTM VM has two VNICs, the external is tagged VLAN65 and the internal is tagged VLAN99.

Point4 is tagged VLAN65, and it's a physical appliance occupying its own switch port.

I'm sure it's something with the UTM configuration, and I'm sure it's something to do with my novice networking knowledge. The reason I'm so sure, is I had an ISA 2010 server in the role of the UTM for six years, and I was able to establish RDP from the DMZ to the internal host with nothing more than a simple external IP->internal IP non-web server publishing rule. But it ain't working with my week-old UTM in place.

By now a solution is probably leaping off the page at you. Please let me know! Thank you.

Here's the switch IP config (Cisco SG-300-20, in L3 mode). VLAN90 and VLAN101 aren't relevant to this discussion - they are an IP camera network, and a NFS network on which to isolate VM storage traffic.

And here's the switch route config:

It looks as though your setup is wrong with the UTM and your ESXi

Just to clarify:

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?

If so, at point No 2 (your internal on your UTM) has to have 2 interfaces (vlan 99 and vlan 100) in order that it can reach both vlans. This can either be one cable in trunk mode connected to the UTM with (ethernet vlan eg E01.99 & E01.100) or 2 interfaces (just ethernet mode) with E01 going to an access port (vlan 99) on the switch and another cable E02 going to an access port (vlan100) on the switch

It looks as though you have missed out vlan100 on the UTM. Once that is in, you need to configure NAT and rules to allow DMZ  (your external) access to clients (your 2nd internal network)

Using ESXi, I would change the VSwitch setup like so:
VSwitch 1 = Your external bound to vlan 65
Vswitch 2 = Your internal (bound to vlan 99) change this to accept ALL Vlans (4095) This then allows this VSwitch to handle vlan 99 and vlan 100.

Bind your UTM interfaces:

External = vlan 65 bind to VSwitch 1
Internal Servers = Vlan 99 bind to VSwitch 2
Internal Clients = Vlan 100 bind to VSwitch 2

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

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