Are these 3750 rules backwards?

my_cisco_forum_id · ‎11-06-2010

I'm trying to make sense of a 3750 switch configuration. It looks like some vlan access rules are backwards, but maybe I'm confused. Here is the pattern of what I'm looking at -- of course with fake IPs / names / etc:

Vlan defined:

vlan 31
name WEB_DMZ

Interface defined:

interface vlan31
ip address 10.0.31.20 0.0.0.255
access-group 131 in

Access list defined:

access-list 131 permit tcp any any established
access-list 131 permit tcp host 10.0.31.12 123.45.67.0 0.0.0.255 eq https
access-list 131 permit tcp host 10.0.31.12 host 123.45.67.17 eq ssh
access-list 131 permit tcp host 10.0.31.12 host 10.0.32.23 eq 1521

My question:

All documentation I've read indicates the first address in the access control entry is the source, and the second is the destination. So in all the entries in the access list 131 above, the source (except for the any any rule) defined is an address within the vlan 31 range, and the destinations are in an external network (lines 2 and 3) or another vlan (line 4). But then in the interface configuration, the list is applied as inbound.

To me that makes it seem like the rules are backwards. Because, as I am interpreting it, the switch is supposed to check traffic headed in to vlan 31 against access list 131. But the sources in the access list are already within vlan 31, and the destinations are outside of it. I.e to take line 4 as an exampled, it is saying "when entering building 31: It is allowed for you to come from building 31 on your way to building 32" -- which makes no sense.

Am I misunderstanding what "in" means? Or are these rules really backwards?? Thanks so much for any help! -- JMH

Peter Paluch · ‎11-06-2010

Joshua,

That ACL does not seem to be "inversed" or something. As you have indicated, it is placed on the interface Vlan31 in the inbound direction, i.e. it affects traffic coming from within VLAN31 and being routed to another VLAN (coming into the SVI for VLAN31 for routing purposes).

What the ACL currently does is:

Allowing the host 10.0.31.12 to access the HTTPS service on all servers in the IP scope 123.45.67.0/24.
Allowing the host 10.0.31.12 to access th machine 123.45.67.17 via SSH
Allowing the host 10.0.31.12 to access the TCP port 1521 on the machine 10.0.32.23
Allowing all TCP segments having the FIN, ACK or RST flag set to leave the VLAN31 (they are replies to TCP connections originated from outside)

Best regards,

Peter

my_cisco_forum_id · ‎11-06-2010

Peter, thanks for responding so quickly.

So what you are saying is that "in" means: traffic into the SVI (I'm thinking of that as the switch's brain) not into addresses within vlan 31. But then, what would "out" ever mean, because everyting has to go into the switch's processor to be processed, right? Sorry if these are dumb questions; it just seems cointerintuitive to me.

my_cisco_forum_id · ‎11-06-2010

...it is placed on the interface Vlan31 in the inbound direction...

What the ACL currently does is:

Allowing the host 10.0.31.12 to access the HTTPS service on all servers in the IP scope 123.45.67.0/24.
Allowing the host 10.0.31.12 to access th machine 123.45.67.17 via SSH
Allowing the host 10.0.31.12 to access the TCP port 1521 on the machine 10.0.32.23
Allowing all TCP segments having the FIN, ACK or RST flag set to leave the VLAN31 (they are replies to TCP connections originated from outside)

...so what then is "inbound"? Because, as you say, access is from VLAN31 to outside resources...

I other words (theoretically): I have a server in VLAN31, with IP address 10.0.31.12. Someone in California, with IP 123.45.67.17 wants to connect to my server via ssh. Packets of stuff will of course be going both directions. But this seems like an in request, because the computer in California wants to get in to my vlan. And the source of a packet containing some keystrokes would be the California computer with the destination being the ssh service on my server. So it seems like the rule (summarized) would be

interface vlan31

access-group 131 in

access-list 131 permit tcp host 123.45.67.17 host 10.0.31.17 eq ssh

^ SOURCE ^ ^ DESTINATION ^

But the rule I'm looking at is the other way around: The source is 10.0.31.17 and the destination is 123.45.67.17. If I want to control access from my server to the ssh service on the computer in California, I would list the source as 10.0.31.17 and destination as 123.45.67.17, but would apply it as:

interface vlan31

access-group 131 out

access-list 131 permit tcp host 10.0.31.17 host 123.45.67.17 eq ssh

^ SOURCE ^ ^ DESTINATION ^

..because the server in my vlan is trying to get out of my vlan to that computer in California. But in the actual rules I'm looking at, the access-list entry looks like an outbound request (host 10.0.31.17 trying to get out of my vlan to 123.45.67.17), but it is applied to the inbound direction of the vlan interface. So...what am I mixing up? Thanks again for your help!

Peter Paluch · ‎11-06-2010

Hello Joshua,

With SVIs, the direction in and out is analogous to the direction of traffic flow with real physical itnerfaces on a router. Think of it this way: the "router" inside the 3750 also has interfaces to VLANs defined on that switch. Naturally, these interfaces are called "Interface Vlan X". Now, the in direction refers to the traffic coming into the interface Vlan X and thus into the "router" while the direction out relates to the traffic being sent out the interface Vlan X and thus leaving the "router", just like it would be if you used a plain interface such as Fa0/0.

The direction in refers to the traffic leaving your VLAN because that traffic comes into your "router" and will be routed out some another interface. The direction out refers to the traffic entering your VLAN because it leaves your "router'" through the interface connected to the particular VLAN. Don't think necessarily in terms of VLAN alone when considering the in/out as that can be confusing for a moment. Think of interface to a particular VLAN. The direction refers to an interface, not to the VLAN itself.

Best regards,

Peter