×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Communication specific between 2 vlans...

Answered Question
Apr 29th, 2003
User Badges:

Hello,

I have 2 vlans and I want a machine A from vlan 1 can communicate with machine B from vlan 2 but no others amchine ebtween vlan.

Actually all machine from vlan 1 can ping all machine from vlan 2. I want limit the traffic between these vlan on one amchine by vlan.

Here a view of my conf

interface Vlan151

ip address 192.168.151.3 255.255.255.0

no ip redirects

standby 1 timers 1 4

standby 151 ip 192.168.151.2

standby 151 timers 1 4

!

interface Vlan152

ip address 192.168.152.3 255.255.255.0

no ip redirects

standby 1 timers 1 4

standby 152 ip 192.168.152.2

standby 152 timers 1 4

!

Gateway of last resort is 172.25.0.1 to network 0.0.0.0


C 192.168.132.0/24 is directly connected, Vlan132

C 192.168.133.0/24 is directly connected, Vlan133

C 192.168.151.0/24 is directly connected, Vlan151

C 192.168.128.0/24 is directly connected, Vlan128

C 172.25.0.0/16 is directly connected, Vlan1

C 192.168.152.0/24 is directly connected, Vlan152

S* 0.0.0.0/0 [1/0] via 172.25.0.1

SWRG1#


I want 192.168.132.6 <--> 192.168.133.6

192.168.132.0/24 <-->192.168.132.0/24

192.168.133.0/24 <-->192.168.133.0/24


Thanks for help.


best regards

Guillaume




Correct Answer by konigl about 14 years 3 months ago

You are correct, you can have only one inbound access-group and one outbound access-group per VLAN interface.


But if you want to, you CAN put all your extended access-list commands into one access-list, and apply it to every interface. Just make sure both directions of traffic flow are accounted for: that is to say, make sure each IP address involved has both a line permitting it to be the source and another line allowing it to be the destination.


Then, it doesn't really matter whether you apply it inbound or outbound on an interface; although technically, just inbound would be better, otherwise, each packet that clears the inbound access-list on one interface, will have to be processed a second time against the same access-list on the outbound journey through another interface, which is a waste of CPU time.


Here's an example:


! Allow all IP traffic between these two hosts

access-list 111 permit ip host 192.168.132.6 host 192.168.133.6

access-list 111 permit ip host 192.168.133.6 host 192.168.132.6


! Allow host .11 on VLAN133 to access POP3 e-mail server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq pop3

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq smtp

access-list 111 permit tcp host 172.25.4.68 eq pop3 host 192.168.133.11

access-list 111 permit tcp host 172.25.4.68 eq smtp host 192.168.133.11


! Allow host .11 on VLAN133 to access web server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.5 eq www

access-list 111 permit tcp host 172.25.4.5 eq www host 192.168.133.11


! Allow host .11 on VLAN133 to access DNS server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit udp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit tcp host 172.25.4.66 eq domain host 192.168.133.11

access-list 111 permit udp host 172.25.4.66 eq domain host 192.168.133.11


! Block all other inter-VLAN IP traffic, and log the denials for later review

access-list 111 deny ip any any log


At the moment, the only reason I can come up with for NOT doing it this way is, if you delete access-list 111 then it affects all the interfaces it has been applied to at once.


Over time, you might want to optimize the order of the access-list commands. Check which permit lines have the most matches, and move them to the top of the list so they get executed sooner. Ideally, the fewer access-list commands that have to be processed before making a forward/don't forward decision, the better.


Hope this helps.


Correct Answer by konigl about 14 years 3 months ago

As the previous post suggests, you can do both inbound and outbound filtering on each interface. I would recommend this only if you want to rigorously control the traffic flow, and make sure that anything which slips through an inbound list gets caught by an outbound list on another interface. It creates a lot of extra work for you, because you have to get the inbound list on each interface coordinated with the outbound lists on all the others. Make a change in your inbound list, and you also have to change all the other outbound lists. If you get your inbound lists right, then the outbound ones are not absolutely necessary; in fact, they just eat up CPU cycles.


What follows is an example inbound access list for interface VLAN132. The "!" at the front of each line indicates a comment, to help explain the purpose of the folloiwing IOS command. The "*" at the end of a comment indicates a note at the end of the access-list. Line spaces are inserted here to keep the comments next to their corresponding IOS commands. Enter these commands from "config term":


------------------------------------------------------------------------------------------

! create named extended access list "Inbound132"

ip access-list extended Inbound132

remark Apply to interface VLAN132 inbound; filters traffic coming in from VLAN132 and going somewhere else.


! let VLAN132 hosts talk to VLAN132 hosts*

permit ip 192.168.132.0 0.0.0.255 192.168.132.0 0.0.0.255


! let the VLAN132 specified host talk to the VLAN133 specified host

permit ip host 192.168.132.6 host 192.168.133.6


! let VLAN132 hosts ping VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo


! let VLAN132 hosts reply to pings from VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo-reply


! block VLAN132 hosts from talking to VLAN133 hosts**

deny ip 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN151 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.151.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN152 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.152.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN128 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.128.0 0.0.0.255 log


! let VLAN132 hosts talk to any host anywhere on the Internet****

permit ip 192.168.132.0 0.0.0.255 any


! block any host from talking to any host anywhere on the Internet*****

deny ip any any log

------------------------------------------------------------------------------------------

* Permits VLAN132 hosts to talk to VLAN132 hosts, if that traffic must go through this device interface at the Layer3 level. Not necessarily needed if this is a router; more likely needed if this is a multilayer switch.


** Blocks any VLAN132 host from talking to any VLAN133 host (except .6 trying to talk to .6 on VLAN133, which was permitted earlier). Logs anything blocked so it can be reviewed later.


*** Logs anything blocked so it can be reviewed later.


**** Assumes Internet is upstream from the VLAN1 interface, and all VLAN132 users are to be permitted access to it; if this rule is executed, it means the previous blocks of VLAN132 traffic to other local VLANs 133, 151, 152, and 128 did not apply.


***** Blocks any other TCP/IP traffic received inbound to this interface. Logs anything blocked so it can be reviewed later. This takes the implicit "deny all" at the end of the access list, and makes it explicit so we can log anything that makes it this far in the list.

------------------------------------------------------------------------------------------


Create similar Inbound access lists for the other VLAN interfaces, deleting the lines you don't want, or changing the IP addresses in the lines you do want to create the desired flow of traffic.


Apply the appropriate access list to each interface. Example:


interface VLAN132

ip access-group Inbound132 in



Hope this helps.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.

Use extended ACLs if you want to base it on L3/L4 info or Standard ACLs if you want to base it on source address. Include the ip addresses you want to allow. If you are in doubt create at the end of the list an entry that denies any and put the keyword "log" at the end and all traffic that doesn't match your ACL will be logged. You could also allow any and still log it...


You will need to create 2 one for each direction. That's one way to do it, anyway.

Apply them as inbound on the interface Vlans.

On how to configure ACL serach for Configuring ACL on CCO.

Correct Answer
konigl Tue, 04/29/2003 - 05:51
User Badges:
  • Gold, 750 points or more

As the previous post suggests, you can do both inbound and outbound filtering on each interface. I would recommend this only if you want to rigorously control the traffic flow, and make sure that anything which slips through an inbound list gets caught by an outbound list on another interface. It creates a lot of extra work for you, because you have to get the inbound list on each interface coordinated with the outbound lists on all the others. Make a change in your inbound list, and you also have to change all the other outbound lists. If you get your inbound lists right, then the outbound ones are not absolutely necessary; in fact, they just eat up CPU cycles.


What follows is an example inbound access list for interface VLAN132. The "!" at the front of each line indicates a comment, to help explain the purpose of the folloiwing IOS command. The "*" at the end of a comment indicates a note at the end of the access-list. Line spaces are inserted here to keep the comments next to their corresponding IOS commands. Enter these commands from "config term":


------------------------------------------------------------------------------------------

! create named extended access list "Inbound132"

ip access-list extended Inbound132

remark Apply to interface VLAN132 inbound; filters traffic coming in from VLAN132 and going somewhere else.


! let VLAN132 hosts talk to VLAN132 hosts*

permit ip 192.168.132.0 0.0.0.255 192.168.132.0 0.0.0.255


! let the VLAN132 specified host talk to the VLAN133 specified host

permit ip host 192.168.132.6 host 192.168.133.6


! let VLAN132 hosts ping VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo


! let VLAN132 hosts reply to pings from VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo-reply


! block VLAN132 hosts from talking to VLAN133 hosts**

deny ip 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN151 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.151.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN152 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.152.0 0.0.0.255 log


! block VLAN132 hosts from talking to VLAN128 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.128.0 0.0.0.255 log


! let VLAN132 hosts talk to any host anywhere on the Internet****

permit ip 192.168.132.0 0.0.0.255 any


! block any host from talking to any host anywhere on the Internet*****

deny ip any any log

------------------------------------------------------------------------------------------

* Permits VLAN132 hosts to talk to VLAN132 hosts, if that traffic must go through this device interface at the Layer3 level. Not necessarily needed if this is a router; more likely needed if this is a multilayer switch.


** Blocks any VLAN132 host from talking to any VLAN133 host (except .6 trying to talk to .6 on VLAN133, which was permitted earlier). Logs anything blocked so it can be reviewed later.


*** Logs anything blocked so it can be reviewed later.


**** Assumes Internet is upstream from the VLAN1 interface, and all VLAN132 users are to be permitted access to it; if this rule is executed, it means the previous blocks of VLAN132 traffic to other local VLANs 133, 151, 152, and 128 did not apply.


***** Blocks any other TCP/IP traffic received inbound to this interface. Logs anything blocked so it can be reviewed later. This takes the implicit "deny all" at the end of the access list, and makes it explicit so we can log anything that makes it this far in the list.

------------------------------------------------------------------------------------------


Create similar Inbound access lists for the other VLAN interfaces, deleting the lines you don't want, or changing the IP addresses in the lines you do want to create the desired flow of traffic.


Apply the appropriate access list to each interface. Example:


interface VLAN132

ip access-group Inbound132 in



Hope this helps.


glmrenard Tue, 04/29/2003 - 05:58
User Badges:

Thank you very much, really.

I have another solution, i think it works :

interface Vlan132

ip address 192.168.132.4 255.255.255.0

ip access-group 111 in

no ip redirects

standby 132 ip 192.168.132.2

standby 132 timers 1 4

standby 132 priority 120

standby 132 preempt

!

interface Vlan133

ip address 192.168.133.4 255.255.255.0

ip access-group 111 out

no ip redirects

standby 133 ip 192.168.133.2

standby 133 timers 1 4

standby 133 priority 120

standby 133 preempt

!

Accesslist 111

permit ip host 192.168.132.6 host 192.168.133.6 (1721 matches)



Do you think it's OK ?


glmrenard Tue, 04/29/2003 - 07:39
User Badges:

I have a problem.

I have to permit other connection in addition to the preceding one

192.168.133.11 <----> 172.25.4.68 (pop+smtp)

192.168.133.11 <----> 172.25.4.5 (http)

192.168.133.11 <----> 172.25.4.66 (domain)


The problem is I thionk there can be only one access-group by vlan interafce an so I am blocked...


vlan 133 / 192.168.133.6 <---> vlan 132 /192.168.132.6

.11<----> vlan 1 / 172.25.4.68,5,66


Is it possible to do that ?

Thanks in advance.


Guillaume

Correct Answer
konigl Tue, 04/29/2003 - 21:12
User Badges:
  • Gold, 750 points or more

You are correct, you can have only one inbound access-group and one outbound access-group per VLAN interface.


But if you want to, you CAN put all your extended access-list commands into one access-list, and apply it to every interface. Just make sure both directions of traffic flow are accounted for: that is to say, make sure each IP address involved has both a line permitting it to be the source and another line allowing it to be the destination.


Then, it doesn't really matter whether you apply it inbound or outbound on an interface; although technically, just inbound would be better, otherwise, each packet that clears the inbound access-list on one interface, will have to be processed a second time against the same access-list on the outbound journey through another interface, which is a waste of CPU time.


Here's an example:


! Allow all IP traffic between these two hosts

access-list 111 permit ip host 192.168.132.6 host 192.168.133.6

access-list 111 permit ip host 192.168.133.6 host 192.168.132.6


! Allow host .11 on VLAN133 to access POP3 e-mail server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq pop3

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq smtp

access-list 111 permit tcp host 172.25.4.68 eq pop3 host 192.168.133.11

access-list 111 permit tcp host 172.25.4.68 eq smtp host 192.168.133.11


! Allow host .11 on VLAN133 to access web server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.5 eq www

access-list 111 permit tcp host 172.25.4.5 eq www host 192.168.133.11


! Allow host .11 on VLAN133 to access DNS server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit udp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit tcp host 172.25.4.66 eq domain host 192.168.133.11

access-list 111 permit udp host 172.25.4.66 eq domain host 192.168.133.11


! Block all other inter-VLAN IP traffic, and log the denials for later review

access-list 111 deny ip any any log


At the moment, the only reason I can come up with for NOT doing it this way is, if you delete access-list 111 then it affects all the interfaces it has been applied to at once.


Over time, you might want to optimize the order of the access-list commands. Check which permit lines have the most matches, and move them to the top of the list so they get executed sooner. Ideally, the fewer access-list commands that have to be processed before making a forward/don't forward decision, the better.


Hope this helps.


Actions

This Discussion