Allow traffic initial from vlan 10 to vlan 20, but not 20 to 10

[ivan.yeung]

Hello,

is it possible in traditional L2 L3 switching without the help of DNA ?

[MHM Cisco World]

are you traffic is TCP ?
if yes then 
ACL TCP with keyword establish is enough of you 

other traffic with only ACL in can be deny to initiate from one side to other.

[ivan.yeung]

All IP traffic.

[Joseph W. Doherty]

As @MHM Cisco World notes, using established would work for TCP traffic, but for all IP traffic, much would depend if the device supports Reflexive ACLs.

[ivan.yeung]

Hi joseph,

i guess using reflexive acl will more administrative overhead? 

[Joseph W. Doherty]

"i guess using reflexive acl will more administrative overhead?"

Compared/relative to?

Any ACL adds administrative overhead, as does using FW features (if supported on router), like CBAC.  But, if you want to only allow traffic in one direction that was invoked/called-for from the other direction, you'll need to do/add "something" to accomplish.

Reflexive ACLs are pretty simple.  What they do is create a timed based mirror ACL for traffic seen going one way, for return traffic.  For example, a mirror ACE would switch source and destination IPs, and if TCP/UDP, swap source and port numbers.

Where something like Reflexive ACLs fails is with protocols that do more than a simple swap at L3 and/or L4.  For example, I believe FTP will only work through a Reflexive ACL if in the "correct" mode (i.e. active vs. passive, although, off-the-top-of-my-head, can't recall which is the "correct" mode for such usage).  FWs, generally, can handle higher levels of the stack, for example, I believe many of them can handle FTP in either active or passive mode.

[paul driver]

Hello

---

@ivan.yeung wrote:

All IP traffic
Allow traffic from vlan 10 to vlan 20, but not 10 to 10

---

Based on the above and using RACL would be applicable as suggested by @Joseph W. Doherty 

Example: (as this using SVI then the  acl logic is reversed

ip access-list extended RACL-OUT
permit ip any 20.20.20.0 0.0.0.255 reflect vl10-traffic

ip access-list extended RACL-IN
evaluate vl10-traffic

interface Vlan10
ip address 10.10.10.254 255.255.255.0
ip access-group RACL-OUT in
ip access-group RACL-IN out

interface Vlan20
ip address 20.20.20.254 255.255.255.0

[ivan.yeung]

This is easy for the my example. But the real situation is there are over 100 vlans allow to 3 vlans, and these 3 vlans not allow access those over 100 vlans…too many administrative overhead to use RACL.

[MHM Cisco World]

assume there are 100 VLAN and there is TCP L4 traffic 
only 
permit tcp any any establish 
ACL command is enough, and the direction is IN 
so any of 100 VLAN want to access to this VLAN will drop why because the SW will search the ACK flag, if it not find in tcp it will drop the packet. 

you mention that the traffic is IP, but this L3 I talking about higher IOS layer.

[Joseph W. Doherty]

Laugh, so there's a "bit more" to your need than the OP asked, eh?

So your new/complex problem is, you would need to implement any FW type ACL on 100 VLANs?

(I had wondered why OP mentioned DNA.)

Well, one possible approach pops to mind, which is: have a transit network between your "interior/protected 100 VLANs" VLANs and your "outside (3) VLANs".  Set protection ACL on transit network.

NB: this cannot be accomplished on same L3 device, i.e. device having any of the 100 or 3 VLANs on it, concurrently, unless using VRF.

[Joseph W. Doherty]

Hmm, just wondering, could not the TCP established or reflexive ACL be applied on SVIs for your 3 VLANs?

I believe it make work, only issue would be, the 3VLANs could not send any outbound traffic unless a) some network external to them initiates a conservation, or b), you also include additional ACEs, granting specific outbound initial access from your 3 VLANs.

[paul driver]

Hello
well this depends on how many of those 100+ vlans require to be segregated  or allow for 1 way communication - VRfs  wont do the job if the latter so if RACLS/ reflective etc..is an option otherwise you will need to think about PVLANs /specific firewall or centralised policy enforcement such as DNA. 

[Joseph W. Doherty]

". . . VRfs  wont do the job . . ."

BTW, what I have in mind, requires them, but alone, they don't do accomplish anything.

Again, VRFs, in my suggestion, or only to deal with the issue if you have any 100 and 3 VLANs, as interfaces, on the same L3 routing device.  In such a situation, the L3 routing device would "see" those networks as "connected" in the same L3 domain.

What I suggested, was something logically like: 100 VLANs/networks <R1> transit network <R2> 3 VLANs/networks

Instead of trying to manage ACLs on all the 100 VLANs/networks or even the 3 VLANs/networks, we only need ACLs on one of the transit networks.  (Of course, depending on your existing topology, logically that may, or may not be simple to accomplish.)

Suppose though we have 100 VLANs/networks <R1> 3 VLANs/networks, how to you create a transit network?  VRFs.

My prior/recent posting, placing ACLs on your 3 VLANs, might be the easiest solution.  Much depends on how all your VLANs direct traffic.

[paul driver]

Hello @Joseph W. Doherty  
what I meant mate was at the end of the day even with vrfs some sort of filtering would still be required - your initial suggestion was spot on in my mind hence why i provided a basic reflective acl example -but then the curve ball was discovering the OP had 100+ vlans