The access-group applies to the whole interface, not just one address. However, you're correct that extended access lists can specify the source address, so it's possible to achieve the results you want.

The access-group applies to the whole interface, not just one address. However, you're correct that extended access lists can specify the source address, so it's possible to achieve the results you want.

That said, your access list above doesn't appear to do what you want, and is arguably applied in the wrong direction.

It's permitting packets from 10.3.3.x to 10.4.4.x, but not return traffic from those packets.

The "established" allows TCP connections initiated from 10.3.3.x to 10.4.4.x. (Attempts to initiate sessions in the other direction will be blocked at the second-last line.)

Applying the access-group to the inbound direction means that packets get filtered before they get routed, which saves some router CPU effort. The sooner you filter out blocked traffic, the less resources get wasted handling it.

NOTE: Secondary addresses are on the same physical network as the primary address. So anybody whose machine has a 10.4.4.x address can get full access to 10.3.3.x machines simply by changing their IP address to a static 10.3.3.x address. So the security that this access-list buys you will be extremely brittle.

"Q: Would this achieve the desired result? Would 10.4.4.0 be denied access to 10.3.3.0 ?"

A: Depends on how the host on 10.4.4.0 is configured. Because 10.3.3.0 and 10.4.4.0 evidently exist on the same physical subnet, it could be possible (barring the use of VLANs) to change the subnetting of a 10.4.4.0 host so that it would not go to the router interface when trying to reach the 10.3.3.0 net. If that were done, any ACL would be immaterial - the 10.4.4.0 host could so whatever it wanted with respect to 10.3.3.0.

The point here is that if you are trying to enhance the security of your environment, this is NOT the way to do it, at least not without VLAN support and enforcement of IP configuration on the hosts.

However, assuming that the 10.4.4.0 hosts are subnetting properly or otherwise forced to use 10.4.4.1 to talk outside of their network/VLAN, then yes, my understanding of how ACLs work tells me your ACL should prevent hosts on 10.4.4.0 from being able to talk to those on 10.3.3.0 (or pretty much anywhere else). Note that this is fairly absolutel - even if a host on 10.3.3.0 sent a packet to a host on 10.4.4.0, the target host could not reply to the sender.

I think Bill is looking for theoretical application, rather than a critique of the chosen subnets or the overall validity of the config or is there is a better way...

>Q: Would this achieve the desired result? Would 10.4.4.0 be denied access to
10.3.3.0 ?

Short answer: I don't think so. As PennGwyn mentioned, it is applied in the wrong direction. It should be applied "IN" as a packet enters the physical interface, since it won't really exit back "through" the interface.

Easy enough to test. Apply it "out" as you have it and try it. Use "show access-list" to see the increasing hit counts one way or the other. If you ping a host, both the permit acl line and the deny acl line should increase the same number of packets. If you can succesfully ping, and there are no hits on either acl line, then reverse the direction to "in" and try again. This time, I'd bet lunch that you won't get a successful ping, and that both lines will increment counters.

Featured Post

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Tired of waiting for your show or movie to load? Are buffering issues a constant problem with your internet connection? Check this article out to see if these simple adjustments are the solution for you.

After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…