cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
398
Views
0
Helpful
7
Replies

Extended access list help

Ableton34
Level 1
Level 1

Hi all,

Quick question regarding an access list issue.

Please see attached diagram, I have successfully forced traffic from the Cisco 3550 to only go to the 172. external network. This is fine. However when I try and get traffic from the 172. network back to the 3550 I am getting stuck, it appears that due to the extended access list on the int g3/12 on the 4507 coming in, when I try and ping the network on the 3550 it doesnt ping.

Cant work out where to place another access-list so the 172 network can get back to 3550, the traffic seems to get dropped at the g3/12 on the 4507 regardless of where i place another access-list.

Any ideas?

Thanks

Steve                  

7 Replies 7

Hello

Seems like your not allowing the retrun traffic -

ip access-list extended ND-traffic

permit ip host 192.168.208.128 172.17.0.0 0.0.0.255

permit ip 172.17.0.0 0.0.0.255 host 192.168.208.128

permit ospf any any

int3/12

ip access-group ND-traffic in

ip access-group ND-traffic out

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Paul

I'm not sure that an acl applied outbound is needed. If you ping from the 172.17.0.0/24 network the acl isn't applied to the traffic going to the 192.168.208.128/26 network  and when the return traffic gets to gi3/12 the acl is checked and the traffic is allowed.

Just to explain, this is a continuation of a long thread with Steve about setting this up. I'm certainly not saying "leave it to me" far from it, but i suspect something else may be going on here.

Steve

An acl applied inbound only affects traffic coming from the 3550. And you are allowing the 192.168.208.128/26 network to go to 172.17.0.0/24 so i can't see how it is the acl.

If you do a traceroute to a 192.168.208.x client  from 172.17.x.x client how far does it get ?

Does the 3550 have a route in the routing table for the 172.17.0.0/24 network ?

Is ther any other config on the 4500 ie. PBR etc. and if so can you post it ?

Jon

Jon.

I can only ping up to the interface on the 4500 facing the 3550 where the inbound acl is placed. When I remove the acl i can ping through.

What i will say is that the OSPF core devices use a network 0.0.0.0 255.255.255.255 area 0 statement and the 3550 is in area 7 as a stub. Could this be the reason I cannot ping after acl applied? The OSPF all interface statement is not shown on the 3550.

No route to the 172.17 network is shown in the routing table on the 3550 only an IA 0.0.0.0/0 via the interface on the 4500.

Thanks Jon

Steve

Steve

If the 3550 has a default route pointing to the 4500 that should be enough although you may, as it said in the previous thread, want to remove OSPF altogether and just have a static route for 172.17.0.0/24 pointing to the 4500 as an added security measuere.

Maybe Paul has seen something i haven't but an acl applied inbound should only apply to traffic coming from the 3550. So when you ping from 172.17.x.x to 192.168.208.x the traffic sholuld go to the 3550 because the acl applied inbound does not apply to this traffic.

The return traffic does though. But your acl is allowing 192.168.208.x to 172.17.x.x so it should be allowed. So can you confirm -

1) the device you are pinging from is actually a 172.17.x.x address

2) the device you are pinging to is actually a 192.168.208.x address

3) that the gi3/12 interface is the one connecting to the 3550 and not to something else

4) that the gi3/12 interface has no other acl applied

5) if you have PBR setup on the gi3/12 interface

I just checked the previous thread and in that thread the interface on the 4500 connecting to the 3550 was fa0/0 and not gi3/12. Are you sure you are applying this acl to the right interface ?

Jon

1) yes

2) yes

3) yes it is gi3/12

4) no other acl only inbound

5) no pbr now, scrapped that as the 4500 didnt support recursive! nice try though ;o)

Interestingly when the acl is applied I cannot ping across the directly connected link between the 4500 and the 3550!

Any ideas?

Cheers

Steve

Interestingly when the acl is applied I cannot ping across the directly connected link between the 4500 and the 3550!

You won't be able to unless the source IP is a 172.17.x.x address and the destination IP is a 192.168.208.x address and when pinging from the 4500 the source IP will not be a 172.17.x.x address.

Sorry to belabour the point but are you absolutely sure when you do the ping your source IP is a 172.17.1.x  address ?

Can you post the exact acl you are using ?

Jon

Hello Jon

I was unstanding this was a filtering request anway no worries.

Res
Paul

Sent from Cisco Technical Support Android App


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking products for a $25 gift card