Vlan access

[Student John]

Hi all, I'm sorry, but I'm sure this question has been answered before but nothing I am trying is working. I am a student and I have to design a small home network and use VLAN's. I have 4 VLAN's setup, 30, 40, 50 & 99. 99 is the management VLAN. What I am trying to do is allow VLAN 99 to communicate with the other VLAN's but not allow the other VLAN's to communicate with 99. My thought process is, lets say I have a security camera on VLAN 30, I want to be able to view it's feed from my main pc on VLAN 99 but I don't want someone who might gain access to the camera to gain access to my main VLAN 99.

I am trying to use ACL's. I have managed to allow pings only in one direction but anything I try after that blocks traffic in both directions.

I have also tried this solution but this blocks traffic in both directions

https://community.cisco.com/t5/routing/prevent-one-vlan-to-acess-other-vlans/td-p/3019573

Here is my config

Router#show run

Building configuration...

Current configuration : 2126 bytes

!

version 15.1

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname Router

!

!

!

!

ip dhcp excluded-address 192.168.99.1 192.168.99.20

ip dhcp excluded-address 192.168.99.254

ip dhcp excluded-address 192.168.50.1 192.168.50.20

ip dhcp excluded-address 192.168.30.1 192.168.30.20

ip dhcp excluded-address 192.168.40.1 192.168.40.20

!

ip dhcp pool Management

network 192.168.99.0 255.255.255.0

default-router 192.168.99.1

ip dhcp pool Guest

network 192.168.50.0 255.255.255.0

default-router 192.168.50.1

ip dhcp pool Security

network 192.168.30.0 255.255.255.0

default-router 192.168.30.1

ip dhcp pool IoT

network 192.168.40.0 255.255.255.0

default-router 192.168.40.1

!

!

!

ip cef

no ipv6 cef

!

!

!

!

license udi pid CISCO2811/K9 sn FTX1017GH75-

!

!

!

!

!

!

!

!

!

!

!

spanning-tree mode pvst

!

!

!

!

!

!

interface FastEthernet0/0

ip address 192.168.99.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/0.30

encapsulation dot1Q 30

ip address 192.168.30.1 255.255.255.0

ip access-group STOP in

!

interface FastEthernet0/0.40

encapsulation dot1Q 40

ip address 192.168.40.1 255.255.255.0

ip access-group STOP_IOT in

!

interface FastEthernet0/0.50

encapsulation dot1Q 50

ip address 192.168.50.1 255.255.255.0

ip access-group STOP_GUEST in

!

interface FastEthernet0/0.99

no ip address

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

!

interface FastEthernet0/1.20

no ip address

!

interface FastEthernet0/1.99

no ip address

!

interface Vlan1

no ip address

shutdown

!

router rip

passive-interface FastEthernet0/1

!

ip classless

!

ip flow-export version 9

!

!

ip access-list extended STOP

deny icmp 192.168.30.0 0.0.0.255 192.168.99.0 0.0.0.255 echo

permit ip any any

ip access-list extended STOP_IOT

deny icmp 192.168.40.0 0.0.0.255 192.168.99.0 0.0.0.255 echo

permit ip any any

ip access-list extended STOP_GUEST

deny icmp 192.168.50.0 0.0.0.255 192.168.99.0 0.0.0.255 echo

permit ip any any

!

banner login ^C Administrators only ^C

!

!

!

!

line con 0

!

line aux 0

!

line vty 0 4

login

!

!

!

end

I have attached the packet tracer file. 

I hope someone in the community can help.

[marce1000]

           - FYI : Community group for Packet Tracer project questions

 M.

[M02@rt37 · Accepted solution]

Hello @Student John 

The current ACLs (STOP, STOP_IOT, and STOP_GUEST) deny all traffic except ICMP echo requests (ping) from other VLANs to VLAN 99. This allows pings but blocks other protocols needed to access the security camera feed.

Adujust like this:

!
interface FastEthernet0/0.30
encapsulation dot1Q 30
ip address 192.168.30.1 255.255.255.0
ip access-group IN_TO_MGMT out  <-- Apply ACL on outgoing traffic
!
interface FastEthernet0/0.40
encapsulation dot1Q 40
ip address 192.168.40.1 255.255.255.0
ip access-group IN_TO_MGMT out  <-- Apply ACL on outgoing traffic
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 192.168.50.1 255.255.255.0
ip access-group IN_TO_MGMT out  <-- Apply ACL on outgoing traffic
!

ip access-list extended IN_TO_MGMT
permit tcp any eq 80 192.168.99.0 0.0.0.255  <-- Allow HTTP traffic to MGMT VLAN
permit udp any eq 554 192.168.99.0 0.0.0.255  <-- Allow RTSP traffic (common for security cameras) to MGMT VLAN
permit icmp any any  <-- Allow pings (already present)
deny ip any any  <-- Deny all other traffic by default

The IN_TO_MGMT ACL is now applied on the outgoing traffic (out) of interfaces belonging to VLANs 30, 40, and 50. This ensures that only allowed traffic from these VLANs can reach the management VLAN (99).

permit tcp any eq 80 192.168.99.0 0.0.0.255: Allows HTTP traffic from any source to the management VLAN. You can adjust this rule based on the specific protocol used to access your camera (e.g., RTSP on port 554).

permit udp any eq 554 192.168.99.0 0.0.0.255: (Optional) If your camera uses RTSP for streaming, add this rule to allow it...

permit icmp any any: Permits pings (already present in your configuration).

deny ip any any: Denies all other traffic by default, preventing unauthorized access to the management VLAN.

If you only want to allow access to the camera from specific devices on other VLANs, you can adjust the source address in the permit rules accordingly. Also, consider assigning an IP address to VLAN 99's interface (FastEthernet0/0.99) for direct management access if needed.

[Student John]

Hi, thank you so much for your help. I will give it a try and get back to you. 

[Joseph W. Doherty]

What you've described, as a requirement for VLAN 99 communication is basically a FW equivalent.  I.e. VLAN 99 can send out whatever it wants, anywhere it wants, but traffic going into it is to be blocked unless it has been requested by a host within VLAN 99.

There are multiple approaches you might use on a real router, don't know what Packet Tracer supports (nor, if this is a student exercise, how sophisticated the solution is expected to be).

Further, as a student exercise, I don't want to provide a solution, I only want to point you to toward solutions.

The "best" approach would be to use the IOS FW feature on the router.

The next best approach would be to use Reflexive ACLs.  A variation of this approach would be to use NAT.  Both approaches, keep session information.  I.e. VLAN 99 outbound traffic triggers a temporary opening for inbound return traffic.

BTW, something like your desire to "see" a video camera's stream, might be surprisingly complex, from a security perspective,  I.e. a VLAN 99 host contacts another VLAN's security camera host, but the security camera host sends the video stream as a separate flow.  I.e. it might not be obvious it's related to VLAN 99's initial outbound/requesting traffic flow.

The "worst" level, would be to have an ACL which explicitly allows and disallows traffic.  Two reasons this would be the "worst" approach.  First, traffic can enter VLAN 99 that hasn't been explicitly requested.  Second, it can make for some very extensive, and tedious, ACLs.

Without any session information, you can somewhat emulate a TCP session for checking an inbound packet is set with the established bit.

Some other traffic types, have their own indications that normally imply an outbound (e.g. ICMP ping echo) vs. an inbound, return traffic, (e.g. ICMP ping echo-reply).  So, you might allow the "return" variants into you VLAN.

Lastly, although you can certainly have ACLs on all the VLANs interfaces, both in and out, for maintainability, you only need an ACL blocking undesired traffic going into VLAN 99.

For example, rather than:

interface FastEthernet0/0
 ip address 192.168.99.1 255.255.255.0

interface FastEthernet0/0.30
 ip address 192.168.30.1 255.255.255.0
 ip access-group STOP in

interface FastEthernet0/0.40
 ip address 192.168.40.1 255.255.255.0
 ip access-group STOP_IOT in

interface FastEthernet0/0.50
 ip address 192.168.50.1 255.255.255.0
 ip access-group STOP_GUEST in

you might:

interface FastEthernet0/0
 ip address 192.168.99.1 255.255.255.0
 ip access-group MgmtFilter out

interface FastEthernet0/0.30
 ip address 192.168.30.1 255.255.255.0

interface FastEthernet0/0.40
 ip address 192.168.40.1 255.255.255.0

interface FastEthernet0/0.50
 ip address 192.168.50.1 255.255.255.0

ip access-list extended MgmtFilter
 allow tcp any any established
 allow icmp any any echo-reply
 allow . . . (whatever other traffic you want to allow in)

[Elliot Dierksen]

I think the current solution solution for this is ZBFW (zone based firewall). I did quite a lot with the IOS FW (aka CBAC), so I am really comfortable with that. It doesn't appear to get much love and more and ZBFW seems to be what gets the attention. Here is another community article talking about how to set that up.

https://community.cisco.com/t5/security-knowledge-base/ios-zone-based-firewall-step-by-step-basic-configuration/ta-p/3142774 

and here is Cisco design guide for ZBFW

https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html 

[Joseph W. Doherty]

Some footnotes to Elliot's info.

His ZBFW link is also found on the web page for my first reference.

He also mentions CBAC.  Information for that is also found on the web page for my first reference.

On a real 2811, ZBFW and/or CBAC, I recall (?) were not found in all IOS feature sets.  Recall you needed something like the Enterprise feature set or the security feature set.  The Packet Tracer 2811 is using the AdvancedIPServices(crypto) feature set.  Don't know if that feature set supports ZBFW and/or CBAC, and even it it "does", when you get into the more IOS advanced features, of Packet Tracer, they may be a subset of the real implementation's and/or not work correctly.  (NB: if PT's doesn't support them, you might also try one of PT's 4K ISRs; which may, or may not, make a difference.)

Also again, unclear if this is an assigned student exercise, and if so, how sophisticated the solution is expected to be.

I didn't mention it in my original reply, but even

"What I am trying to do is allow VLAN 99 to communicate with the other VLAN's but not allow the other VLAN's to communicate with 99."

is a bit unclear, as communication often implies two way correspondence but there can be unidirectional communication.  If the latter, VLAN 99 can send traffic to all the other VLANs, but the other VLANs can send NO traffic to VLAN 99.  But, from the rest of your info, I believe the intent is for VLAN # ==>> VLAN 99 communication only if the communication is initiated by VLAN 99.

[Student John]

Hi, thank you all for your suggestions. I am only a few months into this course but I have probably made my network too complicated for where I am. 

But again, thank you all for your suggestions. The Cisco forums seem to have a wealth of information in them.

After learning about ACL's I wrongly assumed there would be a simpler solution to allowing one way VLAN communication with other VLAN's. 

[M02@rt37]

You're so welcome @Student John