Have a query that I can't quite fathom out.
I have an access rule on my asa5510 that permits 'full internet' for those members of that group (me included) and works fine.
For some reason I have a DHCP PC that is also gaining full internet access (they are not in this group), but for every other PC access is being blocked. The ones that are being blocked are what I would expect.
I also have a rule that permits TCP ftp (21) and TCP SSH sftp (22) with the sftp working fine for said working user.
I've checked the logging using a test pc and see for following deny 'Deny'
|4||Jul 15 2011||09:45:42||106023||10.0.0.76||1077||188.8.131.52||80||Deny tcp src inside:10.0.0.76/1077 dst outside:184.108.40.206/80 by access-group "inside_access_in" [0x565b3da1, 0x0]|
I can see no NAT or Access rule that explains why one DHCP PC has full access and another nothing?
which version do you run on the ASA and what is defined in access-lists "inside_access_in". Also would be great to know on which interface you put this ACL and where the traffic is initated.
I beleive this is a configuration issue. May be it would be great if you could send me the "show run" output by email and I can check it for you.
We need to check which interface has the ACL, what is the security number, what the ACL contains and how it is related by the traffic.
You also have the option to run the packet-tracer which will show you where in the config is the problem.
I checked your config and it is a basic configuration issue. Your ACL is simply deny the traffic. for the example above what you give us this line is denying:
access-group inside_access_in in interface inside
access-list inside_access_in extended deny ip InternalNetwork 255.255.255.0 any
You can use the packet tracer feature to check which line not let the traffic:
"packet-tracer input inside tcp 10.0.0.76 2134 220.127.116.11 80 det"
I'm looking at the ACL Manager now for the "inside_access_in" and can see the rule permitting ftp.
Source = InternalNetwork
Destination = any
Service = ftp/ftp-data
Action = permit
I just ran the Packet Tracer using Interface = inside, packet type = tcp and set the source as an internal ip and the destination to the ftp, all passed.
When I swapped the source and destination around and set to outside it failed on our outside rule (incoming) which I guess is where the problem is, any, any IP, deny?
please note that the order is very important. Indeed you have that rule, but the deny is at first.
access-list inside_access_in line 17 extended deny ip InternalNetwork 255.255.255.0 any <-- this will drop the packet
access-list inside_access_in line 20 extended permit tcp InternalNetwork 255.255.255.0 any eq ftp
If you change the source and destination it means you changing the way where the connection initiated. It means when you tried you simulated that FTP server initiate a connection to your internal host. If you want this you have to allow the traffic by acl and nat rules.
I recommend to read this documentation, it explaines the configuration and troubleshoot of ACLs.
Yes, I'm aware that the order is important, especially if a deny is executed before a permit.
Though line 11 = access-list inside_access_in extended permit tcp InternalNetwork 255.255.255.0 any eq ftp
and line 22 = access-list inside_access_in extended deny ip InternalNetwork 255.255.255.0 any
The above suggests it should be fine.
If I replace the ftp for http, browsing the Internet works.
I simply the replaced the source/destination to test the packet transfer route.
When I run the packet tracer, nothing fails.
That's for the reading tips but unless the logic makes sense, reading isn't going to help me and from what I see in the GUI, it's not tallying.
On another note, I can clearly see ACL rule within inside_access_in relating to a permet ftp, but this is not showing in the running config. I also set an any, any which worked one minute and then failed.