Understanding Cisco IP Access List

[b.burk]

Hello,

Apologies if this is posted on the wrong board, I am new to Cisco forums. I am having some difficulty understanding the Cisco IOS commands 'ip access-list' and 'ip access-group' syntax. Our office router has three network interfaces now. Previously, we had two, NATing one as inside and one as outside. Recently, we have incorporated Virtual Machines into our office network. I installed a FE card into the expansion slot of our router to handle this new setup. Our VM box has two NICs, one of which is linked via crossover to the router interface card. The other NIC, is used as VMWare's management, which I have linked to a dummy pc, which has access to the web interface, but not the internet, as I have separated the two NICs from communication inside the VM box.

The plan is to be able to secure shell (ssh) access the virtual machines from inside the office LAN, and from outside as well. I have plans to operate an OpenVPN tunnel, with an endpoint inside the office LAN to drive this. Let me be clear. When I say 'office LAN', i mean 192.168.1.0/24. When i say 'vm LAN', i mean 11.11.11.0/24. I have read a bit about the 'access-list' command, but I cannot seem to configure this properly.

TL;DR

x2 interfaces

    192.168.1.0/24 -> g0/1

    11.11.11.0/24 -> f0/0/0

I need the ability to ssh the 11.11.11.0 network, from 192.168.1.0

I need to prevent access to the 192.168.1.0 network, from the 11.11.11.0 network

running-config

ip dhcp excluded-address 192.168.1.40 192.168.1.255
ip dhcp excluded-address 11.11.11.20 11.11.11.255
!         
ip dhcp pool DHCP_POOL
 import all
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.40 
 dns-server 192.168.1.45 
 lease 0 12
!
ip dhcp pool DHCP_POOL_VM
 import all
 network 11.11.11.0 255.255.255.0
 default-router 11.11.11.20 
 dns-server 208.67.222.222 
!
!         
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!         
interface GigabitEthernet0/0
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 192.168.1.40 255.255.255.0
 ip access-group BAN_11 out
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface FastEthernet0/0/0
 ip address 11.11.11.20 255.255.255.0
 ip access-group BAN_168 in
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
ip forward-protocol nd
!
!
ip nat inside source list 7 interface GigabitEthernet0/0 overload
!
ip access-list extended BAN_11
 permit ip 192.168.1.0 0.0.0.255 any
 permit tcp 11.11.11.0 0.0.0.255 any established
 deny   ip 11.11.11.0 0.0.0.255 any
 permit ip any any
ip access-list extended BAN_168
 permit ip any any
!
access-list 7 permit 192.168.1.0 0.0.0.255
access-list 7 permit 11.11.11.0 0.0.0.255
!

[Troy Jackson]

Hi, 

The IP access-list is used to create access policies and the IP access-group command is used to apply the policy either inbound (traffic entering the interface toward the device) or outbound (Traffic leaving an interface outside the device). You can only use one access list per interface and per direction (in or out). If you are using extended ACLs like in your example they should be used closer to the source. 

**I need the ability to ssh the 11.11.11.0 network, from 192.168.1.0** (In this case you don't need an ACL here. But I'll block traffic to the server subnet for the example)

no ip access-list extended BAN_11

ip access-list extended BAN_11

permit tcp 192.168.1.0 0.0.0.255 11.11.11.0 0.0.0.255 eq ssh

deny ip 192.168.1.0. 0.0.0.255 11.11.11.0 0.0.0.255

permit ip any any

!

interface GigabitEthernet0/1
no ip access-group BAN_11 out 

ip access-group BAN_11 in

**I need to prevent access to the 192.168.1.0 network, from the 11.11.11.0 network** (The source here is on f0/0 inbound and we will need to add an extra rule to let the ssh traffic in before blocking all traffic to 192.168.1.0)

ip access-list extended BAN_168

permit tcp 11.11.11.0 0.0.0.255 eq ssh 192.168.1.0 0.0.0.255

deny ip 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255

permit ip any any

!

interface FastEthernet0/0/0
ip access-group BAN_168 in

[Julio E. Moisa]

Hi, 

Syntaxis for an ACL is:

Numeric (There is also named ACLs)

access-list <id> <permit/deny> <protocol tcp, udp, ip, icmp...> <source host/network> <source wildcard> <eq source port/range> <destination host/network> <destination wildcard> <eq destination port/range> 

Ip access-group <ACL numer or name> <direction IN or OUT> is applied under the interface who will be filtering the traffic. Basically they are applied under interfaces connecting other Layer 3 devices. 

Based on this you can set the direction for the ACL, if your source network is inside of your company network and it should have access to the external network, so the access-group applied under the outside interface should be OUT. 

External network: 10.0.0.0/24
Internal network: 172.16.1.0/24

access-list 100 permit ip 172.16.1.0 0.0.0.255 10.0.0.0 0.0.0.255 

interface g0/0

description TO-OUTSIDE
ip access-group 100 OUT

If an external network wants access to the Interntal network the direction should be IN: 

External network: 10.0.0.0/24
Internal network: 172.16.1.0/24

access-list 100 permit ip 10.0.0.0 0.0.0.255 172.16.1.0 0.0.0.255

interface g0/0

description TO-OUTSIDE
ip access-group 100 IN

  OUT

<------ G0/0                      G0/1

   IN                     ROUTER  

------> G0/0                      G0/1

Hope it is useful

:-)

[Richard Burts]

The original post asks questions about two commands, ip access-list and ip access-group. So first let us deal with that part of the question. ip access-list evaluates traffic between ip addresses and takes some action on that traffic. The access list defined can be used in many ways. We tend to think of access lists when they act on traffic going through an interface to filter that traffic (what to permit and what to deny). But there are many uses for access lists and that includes identifying traffic for address translation, for identifying traffic for Policy Based Routing, for identifying interesting traffic for IPSEC tunnels, and many other uses. So after we configure the list using ip access-list then we must define how that access list is to be used. And that is what ip access-group does. ip access-group assigns an access list to filter traffic going through an interface. Note that when we assign an access list to filter traffic going through an interface we must specify the direction of the traffic (in or out) and that has significance for what addresses are the source and what addresses are the destination. There must be a correlation between what direction the access list is used and what addresses are the source. 

There is sometimes confusion about the meaning of in and out when configuring ip access-group. The simple way to understand this is to think in terms of the router. When we configure an access-group as "in" then it is filtering traffic from connected devices into the router interface. And when we configure an access-group as "out" then it is filtering traffic from the router out to the connected devices.

The original post describes in general terms how they want the network to operate and then focuses on two objectives:

I need the ability to ssh the 11.11.11.0 network, from 192.168.1.0

I need to prevent access to the 192.168.1.0 network, from the 11.11.11.0 network

The first objective is clear. The second objective is less clear. It specifies no traffic from 11.11.11 to 192.168.1 but does not address whether traffic from 192.168.1 to 11.11.11 is allowed. If the requirement is that only SSH (and nothing else) is permitted from 192.168.1 to 11.11.11 then the configuration is simple. If other traffic from 192.168.1 is to be allowed then the configuration becomes more complex. We need the original poster to provide clarification about this.

Since the first objective is clear we can discuss how to implement this. We should get the clarification of the second objective before we discuss how to implement that. If we want to allow SSH from 192.168.1 to 11.11.11 we have two alternatives. We can use an access-list and access-group inbound on G0/1 to permit SSH where the source is 192.168.1 and destination is 11.11.11 or we can use an access-list and access-group outbound on FE0/0/0. Note that if we use the access-list and access-group on FE0/0/0 then we would also need the access-list to permit SSH traffic with source address of traffic coming from the outside interface G0/0. Also note that theoretically we could use access-list and access-group inbound on FE0/0/0 or outbound on G0/1 to limit responses to SSH and thereby control SSH access - but this would be complex and awkward and I would not recommend this approach.

HTH

Rick

[b.burk]

Rick, 

I am looking to isolate the 11.11.11.0 network from any other VLANs I may establish in the future. The 192.168.1.0 network I would like to be able to establish a connection to the 11.11.11.0 network (tcp/udp). However I would like to prevent the 11.11.11.0 network from doing so to the 192.168.1.0 network.

Uplink(g0/0)<---- f0/0/0

Uplink(g0/0)<---- g0/1 - - - - > f0/0/0

[Richard Burts]

Thanks for the additional information. I do not understand the sort of diagram in your post. It seems to show g0/0 with two paths to the 11.11.11 and I am not sure what it means or how to respond to it. So let me respond to the part of the post that I do understand. 

You say that there may be other vlans in the future and you want them isolated from the vm network. That should be easy. You would have two choices - you could configure and apply an access list on the new vlan interface which would deny traffic from that subnet to the vm subnet and then permit other traffic. Or you could configure and apply an access list on the vlan interface for the vm network. That access list would deny traffic from the new vlan subnets and permit traffic from the office network (192.168.1). From my perspective I would choose to do the access list on the vm vlan interface since a single access list there could control traffic from multiple new vlans. But either approach should work.

I understand that you want the office network to be able to initiate traffic to the vm network but the vm network to not be able to initiate traffic to the office network. That is a challenge with an IOS switch  or router. The issue is that for communication to be successful one network initiates the traffic and the other network must be able to respond. If you configure an access list for the vm network vlan interface that denies traffic from the vm network to the office network, then you will prevent the vm network being able to respond to the office  network traffic.

There is an option in the access list that will help with responses to tcp traffic (use the "established" parameter in the permit for tcp traffic). But for non tcp traffic it is a challenge. With devices that do stateful inspection, such as the ASA, it is much easier to enable the office to initiate traffic to vm but not enable vm to initiate traffic to office. To control the non tcp traffic you will probably want to look into using reflexive access lists. Here is a link that has information that I hope you will find helpful.

https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfreflx.html

HTH

Rick

[b.burk]

Ok. I think I understand. Im going to make an access list, allowing only established tcp (i.e. ACK) traffic out of the vm vlan (11.11.11.0)

interface FastEthernet0/0/0
    ip address 11.11.11.20 255.255.255.0
    ip access-group 101 out
    ip nat inside
    ip virtual-reassembly in
    duplex auto
    speed auto

access-list 101 permit tcp 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255 established
access-list 101 deny ip 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip any any

I'll see how this works.

[Richard Burts]

Thanks for the update. Most of my experience with tcp established it has been implemented as an inbound ACL on the interface where the original traffic was sent. But in your situation it does make much better sense to use it as outbound on the vm network interface. I would think it would work for you for the tcp traffic. Note that this does not have any effect on the udp traffic, or icmp traffic, or any other non tcp traffic from the office to vm and vm responses to the office.

Implement this and let us know what are the results.

HTH

Rick

[b.burk]

Well, its not working as expected. Placing the access-list on the VM Network outbound does the opposite effect, denying all other vlans (Office Network) to the VM Network, but allowing VM Network access to the Office Network. Specifically, I can ICMP/TCP (ping/ssh) the Office Network from the VM Network, but not if the roles are reversed.

EDIT: I think this may be a problem I overlooked with TCP. I want the Office Network, only, to be able to initiate a TCP connection. I may be denying the ACK and subsequent SYN, from the VM Network, after it receives a SYN from the Office Network. It is true that I want to allow established connections, but I may be denying the ability for them to form. I may only need to deny SYN from the VM Network going outbound, unless it has received a SYN from another vlan (Office Network)

Current configuration:

interface FastEthernet0/0/0
 ip address 11.11.11.20 255.255.255.0
 ip access-group 101 out
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!

access-list 101 permit tcp 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255 established
access-list 101 deny   ip 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip any any

I've reloaded the router several times and rebooted the wireless client i use for testing to remove that possibility. I'm gonna try an additional access-list on g0/1, with the identical configuration for the f0/0/0 access-list, except that g0/1 list is inbound and the f0/0/0 is outbound.

So it should look like this:

interface GigabitEthernet0/1
 ip address 192.168.1.40 255.255.255.0
 ip access-group 102 in
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!         
interface FastEthernet0/0/0
 ip address 11.11.11.20 255.255.255.0
 ip access-group 101 out
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
access-list 101 permit tcp 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255 established
access-list 101 deny ip 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip any any
access-list 102 permit tcp 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255 established
access-list 102 deny ip 11.11.11.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 102 permit ip any any

For syntax simplicity's sake, I've made two access-lists, even though they are identical. Can an access-list be used as inbound on one interface, but outbound on another? I would assume so, but I'm trying to remove all possible syntactical errors from my config

EDIT: I'm gonna do some reading on the subject of TCP. I'm convinced I have denied the ability for these connections to form. Let me know what you think.

[Richard Burts]

Thanks for the additional information. The major issue with what you have tried to do is a misunderstanding about the differences of in and out when you apply the access list. In your first effort on Fast0/0/0 you apply the access-group as out. Remember that in and out are done in reference to the router interface. So access-group out is going from the router interface to the connected hosts. This means that in the access list 11.11.11 should be the destination. But your ACL makes 11.11.11 the source.

On your effort with Gig0/1 you apply the access-group as in. Using it as in means that it is coming from the connected hosts into the router interface. In this case 192.168.1 should be the source address but you have it as the destination.

Try reversing the in/out of both access-group and let us know if the behavior changes.

HTH

Rick