cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1603
Views
10
Helpful
11
Replies

Access-List: Permitting Services to a Host while denying the same services to all and permitting all

nwekechampion
Level 3
Level 3

Hi all,

 

I was just checking if this is possible.

I need to permit services to a host behind my router from specific hosts  (eg 22 and 80), while denying services to same host from any on the internet, but also permitting other traffic. Is this a possibility eg:

 

ACLS:

1. Allow web access to 192.168.1.2 from only 10.10.0.0/24 network

2. Allow SSh access to 192.168.1.2 from only 10.10.0.0/24 network

3. Deny all Web access apart from the above to 192.168.1.2

4. Deny all ssh access apart from the above to 192.168.1.2

5. permit all traffic

 

 

2 Accepted Solutions

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

Yes it is possible and your question correctly describes the approach to use. The acl might look something like this

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 80

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 443

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 22

access-list 101 deny tcp any host 192.168.1.2 eq 80

access-list 101 deny tcp any host 192.168.1.2 eq 443

access-list 101 deny tcp any host 192.168.1.2 eq 22

access-list 102 permit ip any any

Then apply the acl outbound on the interface where 192.168.1.2 is connected.

HTH

Rick

View solution in original post

I am glad that my suggestions have been helpful. I am not clear what you mean when you say that the access applied in on the WAN interface would not apply. Do you really mean that the command to apply the acl to the interface (access-group) is not accepted? Or do you mean that when used with access-group on WAN interface it does not work?

 

If you mean does not work I think I understand that. If you mean the command is not accepted then I am puzzled about it. Looking at the posted config clarifies that the WAN interfaces have the static nat for incoming traffic. So coming into the WAN interface the destination address of the packet would not be 192.168.1.2. So I can see how the acl might not work inbound on WAN interface.

 

As for 2) question using object group in access list is helpful when you have multiple things (multiple addresses, multiple protocol ports, etc) that are mentioned multiple times and you can include them in a single reference. In that sense object group might be helpful when you want to combine multiple access lists into one.

HTH

Rick

View solution in original post

11 Replies 11

Richard Burts
Hall of Fame
Hall of Fame

Yes it is possible and your question correctly describes the approach to use. The acl might look something like this

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 80

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 443

access-list 101 permit tcp 10.10.0.0 0.0.0.255 host 192.168.1.2 eq 22

access-list 101 deny tcp any host 192.168.1.2 eq 80

access-list 101 deny tcp any host 192.168.1.2 eq 443

access-list 101 deny tcp any host 192.168.1.2 eq 22

access-list 102 permit ip any any

Then apply the acl outbound on the interface where 192.168.1.2 is connected.

HTH

Rick

Thanks Richard,

That worked perfectly!

2 questions:

 

1. Why apply from LAN interface on router outbound? why not on interface facing internet inbound?

2. If I wanted to group the acls (like you had 101), say 101,102,103 ... how do I group them separately and still lump it all and apply to an interface? Bearing in mind you can only have one access-group (ie in this case 101 per interface)?

 

Hope I make sense?

I am glad that my suggestion did work for you. You ask two question about access lists.

1) As far as assignment of the access list there are several possibilities and perhaps it is a judgement call about which to use. One possibility might be assigned to the Internet inbound interface. This would be a good choice if the source addresses were public/Internet addresses going to inside/private addresses. But that is not the case with this access list. So I would not suggest assigning to the Internet interface. A better possibility might be to assign the access list to the interface where the source address is located. That way you check the traffic at the origin and if it is going to be denied then you deny it before you use any resources to forward the traffic through your network. The possibility that I suggested is to assign the access list to the interface where the destination addresses are located. This was based on an assumption that the source addresses were probably servers going to many destinations and the destination addresses were probably clients. In that case checking the traffic at the source would probably be a higher volume of traffic to check. So checking at the destination might require less processing than at the source. Either of these alternatives would work and it is a matter of degree in deciding which interface to use for assigning the access list.

 

It occurs to me that an additional factor to consider about where to assign the access list would be whether either interface or both interfaces already have an access list assigned (in the appropriate direction). If one interface does already have an access list assigned and the other does not then it would be easier and better to add some statements to the existing access list than to create a new access list and assign it.

 

2) Your second question is about combining access lists. Unfortunately that is not possible. You can have one access list in and one access list out per interface. If you had access lists 101, 102, and 103 and you wanted to combine them you could create access list 104 and combine the logic of the 3 separate lists into a single list.

 

Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

Many Thanks Richard, 

It has been an absolute pleasure on here it has been of great help to me in very desperate times.

 

With the above on access-lists, I still have a problem when I apply the acl "In-Bound" on the WAN interfaces of the router.

It just would not apply. However, when i do apply to the interface of the "192.168.1.2/24" network, "outbound", it does apply.

Could you explain why this would be the case please

 

I have attached a network diagram to help give a visual to my little conundrum.

In the diagram:

"YBGC" is the local router of a client.

Webserver is the: 192.168.1.2 device with portforwarding applied

YBGC has to WAN links with failover applied 

 

Also regarding question2:

Does Obect-group in ACLs help solve the issue of combining several  ACL groups  into one major ACL ?

 

Thanks again.

 

Would really appreciate your feedback

I am glad that my suggestions have been helpful. I am not clear what you mean when you say that the access applied in on the WAN interface would not apply. Do you really mean that the command to apply the acl to the interface (access-group) is not accepted? Or do you mean that when used with access-group on WAN interface it does not work?

 

If you mean does not work I think I understand that. If you mean the command is not accepted then I am puzzled about it. Looking at the posted config clarifies that the WAN interfaces have the static nat for incoming traffic. So coming into the WAN interface the destination address of the packet would not be 192.168.1.2. So I can see how the acl might not work inbound on WAN interface.

 

As for 2) question using object group in access list is helpful when you have multiple things (multiple addresses, multiple protocol ports, etc) that are mentioned multiple times and you can include them in a single reference. In that sense object group might be helpful when you want to combine multiple access lists into one.

HTH

Rick

HI Rick,

I am sorry for the confusion..
I meant when I applied it to the WAN interfaces on the YBGC router "inbound", I do not get the required results: as in it would the YBGC router would still behave as normal allowing all traffic (as though the acl was not even in place).
PLease let me know if properly understood.

Regards

Thank you for the clarification. If your comment means it did not achieve the desired result then I certainly understand it. And I hope that my suggested explanation for why it did not achieve the desired result was helpful. Does that explanation make sense to you?

HTH

Rick

Hi Rick,

So if I am to understand you correctly based on below:

"the posted config clarifies that the WAN interfaces have the static nat for incoming traffic. So coming into the WAN interface the destination address of the packet would not be 192.168.1.2."

The static NAT for both interfaces will prevent this from working inbound.

Other words " Access list should have the host address as the WAN interfaces of the destination router?"

AS IN: permit tcp 10.10.10.0 0.0.0.255 host 110.60.65.1 eq www ==> FOR EXAMPLE

Many Thanks

As I understand your diagram I believe this is correct.

HTH

Rick

HI Rick,

Yup! It does work.
I tried it on my lab based on your explanation.
Changed destination IP to WANs' on ACL, Applied to WAN inbound.
Thanks so much for your help.

Hi Rick,

Would really appreciate your reply to the below when you can..

Thanks
Review Cisco Networking for a $25 gift card