1

Hi folks,
I hope y’all can point out what I’m doing wrong here.
I have two VLans and I’m trying to restrict traffic between them.
Both have machines that are members of the same domain.
VLan A has no restrictions / ACLs
On VLan B I’m building ACLs to restrict traffic.
I’ve permitted all IP traffic to/from two hosts on each VLan for testing.
I’ve also allowed all IP traffic from VLan B to/from the domain controllers and DNS servers.

When I try to use Windows file explorer to navigate from VLan A host o VLan B host, I get an error message about no logon servers or an error about domain not available. Neither is true.
I run wireshark on both machines and I don’t see any traffic except TCP 445 between the two.

To make things even more frustrating, if I remove the ACLs from VLan B, then open file explorer I can connect no problem. When I re-add the ACLs I can still connect no problem.

What is going on here?!?
Thanks for your help!

3 Spice ups
2

When you have the ACLs enabled are you able to contact the domain controller?

1 Spice up
3

There’s a lot of information missing here, so to better troubleshoot we would need to fill in some gaps.

I’ve permitted all IP traffic to/from two hosts on each VLan for testing.

When you say “all IP traffic” do you mean all ports and protocols from the specified IP address? Meaning, both Hosts have an ACL rule to ALLOW all traffic FROM targethost IP and ALSO have a rule to ALLOW all traffic OUT with a destination of targethost IP.

When I try to use Windows file explorer to navigate from VLan A host o VLan B host,

What do you mean by this specifically? Do you mean you are on Host A and trying to access the drive of Host B like with using \\hostname\c$ in File Explorer?
To authenticate to any host on a domain, the host needs to be able to communicate with the domain controllers (which I’m assuming are running Active Directory). So if you have a default ACL on a host, it may be automatically denying the ports needed to do authentication. Even though your source machine can reach the target machine, your source machine may still need to be able to connect to the authentication server.

I think the part I’m missing is what you mean by “I can connect”. Usually that means a ping test or a test-netconnection, so I’m confused what you mean by using File Explorer.

4

Yes; I can use the LDP tool to connect to the DCs

5

Apologies for the gaps; I’m still a novice.

When you say “all IP traffic” do you mean all ports and protocols from the specified IP address?

I have entries on both the in and out ACL like such
permit ip host x.x.x.x host y.y.y.y
permit ip host y.y.y.y host x.x.x.x
This is just for testing, ultimately I want these narrowed down to just required ports.

Do you mean you are on Host A and trying to access the drive of Host B like with using \\hostname\c$ in File Explorer?

Yes; though I’m using the IP address in the UNC path. So it looks like \x.x.x.x\sharename

"I can connect”

This means that I can open File Explorer (explorer.exe; icon is a folder) in Windows on Host A, type \x.x.x.x\sharename and access files/ folders. I have permissions to read/ write. Everything I want.
Ping/ ICMP traffic always works.

So if you have a default ACL on a host, it may be automatically denying the ports needed to do authentication

This is my main struggle – I’ve allowed all traffic to/ from the domain controllers from both hosts. I don’t see any requests going from either machine to the DC (running LDAP) but I still
get the errors.

6

Here’s the wireshark log from Host B when I attempt to connect from Host A
There’s no other traffic to or from Host B. Why does it kick out an error?

Capture
Capture668×203 16 KB
7

You don’t say what brand devices you are using, but some devices won’t break established sessions when you apply an ACL.. Meraki I believe works this way.. meaning the session has to expire or close before the new ACL will apply to it.

8

Good point.
ACLs are being applied on Cisco WS-C3750G-24T-E L3 switch.
Workstations are Windows 10 x64 (one virtual, one physical)
Domain controllers are Windows Server 2016 or Server 2022

1 Spice up
10

Copilot says your ACL Changes won’t apply to existing connections on that switch

On a Cisco WS-C3750G-24T-E Layer 3 switch, changes to Access Control Lists (ACLs) typically only affect new connections, not existing ones. Here’s a more detailed explanation:

:counterclockwise_arrows_button: Behavior of ACL Changes

  • Stateless ACLs (standard/extended IP ACLs): These are the most common on Cisco Layer 3 switches like the 3750 series. They do not track connection state, so:
    • New ACL rules apply only to new traffic.
    • Existing flows (e.g., established TCP sessions) are not immediately dropped unless the new ACL explicitly blocks the ongoing traffic and the switch re-evaluates the flow.
  • Established TCP Sessions: If a session is already established and the ACL is changed to block that type of traffic:
    • The session may continue until it ends naturally.
    • However, if the switch re-evaluates the session (e.g., due to a routing change or interface flap), the new ACL rules will be enforced.
  • UDP and Stateless Protocols: Since these don’t have a connection state, any new packet is evaluated against the current ACL. So changes can immediately affect UDP traffic.

:hammer_and_wrench: Best Practices

  • Use the established keyword in ACLs to allow return traffic for TCP sessions.
  • Be cautious when applying ACLs to interfaces with active traffic—test in a lab or during maintenance windows if possible.
11

Are the DCs on the VLAN A? or another vlan/elsewhere?

What type of ACL? IP, vlan etc? probably IP and if so is this applied inbound to VLAN B only (ip access-group xxx in - on the vlan interface)? or in both directions.

Typically an ACL is applied inbound so it will only filter traffic initiated by a VLAN B host.
so a simple ACL could be: allow to the DCs, deny all else.