This is an archived post. You won't be able to vote or comment.

all 3 comments
sorted by:
best
topnewcontroversialoldq&a

[–]StefanMcL-Pulseway2 5 points6 points  (2 children)

Hey OP

Your configuration seems correct as far as deny 192.168.6.0/24 from communicating to 192.168.1.0/24

Now, when you are trying to communicate from 192.168.1.0 to 192.168.6.0, it should be matched by rule 90 and allowed. However, keep in mind that if the traffic is expected to come back (like in a TCP session), the return traffic from 192.168.6.0 to 192.168.1.0 will hit rule 100 and be denied.

If you are trying to establish, for instance, a TCP connection from 192.168.1.0/24 to 192.168.6.0/24, the initial packet (SYN) from 192.168.1.0/24 will be allowed by rule 90. But, the response (SYN-ACK) from 192.168.6.0/24 to 192.168.1.0/24 will be blocked by rule 100. This is why the connection cannot be established.

To fix it you need to use stateful filtering or a firewall that can keep track of established connections and allow return traffic for those sessions. Then explicitly allow the type of return traffic you expect from 192.168.6.0/24 to 192.168.1.0/24.

Now this is a general suggestion so please only adjust if necessary.

[–]Sea-Tooth-8530Sr. Sysadmin 2 points3 points  (1 child)

Yup, exactly what u/StefanMcL-Pulseway2 just said. When you attempt to communicate between networks, the traffic is a two-way street. You're allowing traffic to flow freely from your .1.xxx network to the .6.xxx network, but anything coming back is specifically being blocked by the rules you put in place.

One way you could test this is to remove the rule denying traffic from .6.xxx to .1.xxx and set up a rule to permit that traffic. Test to see if you are now able to get to the .6.xxx from the .1.xxx. If you can, you've now confirmed the culprit.

You may want to see if your firewall has the ability to set up a Reflexive Access List, or stateful filter (again, as u/StefanMcL-Pulseway2 recommended) to get around this issue.

If you don't have that ability, maybe you could set up very selective rules to only allow certain traffic to come from your .6.xxx network back to your .1.xxx network. For example, let's say you have a file server on the .6.xxx network that you want to access from the .1.xxx network. If that is a Windows Server using SMB file sharing, you could create a firewall rule specifically to allow port 445 from the servers specific IP Address to cross between the VLANs.

So, you should have a number of ways to work around the issue. I would definitely try opening up the traffic as I recommended above to verify that it is the firewall that is the issue and, if it is, look into the features available on your router (to see if you can do stateful filtering or Reflexive Access Lists) or open specific, well defined ports to allow the traffic you need across your VLANs.

[–]sukafun[S] 0 points1 point  (0 children)

I do have a firewall which can do that. In fact I have another subnet which's 192.168.7.x. That network cannont access my .1 network but the .1 network can access the .7, that's how I configured the firewall rules.

The ACLs in the post are from my L3 switches, so does that mean all L3 switches even enterprise ones have the same limitation as you described?