Why does this ACL command work but this other one not work?

[John Robinson IV]

Scenario: Interface Vlan 200 has an An ACL on it with this command (these names are made up so bear with me).

ip access-group ACL-Block-Stuff-IN in

We want data to travel to remote server at 2.2.2.2 to an endpoint at 192.168.1.237 as well as from that endpoint back to the server over port 9000.

Here's part of the ACL

Extended IP access list ACL-Block-Stuff-IN
10 permit icmp any any echo
20 permit icmp any any echo-reply
30 deny ip any 10.0.0.0 0.0.0.255 
40 deny ip any 172.16.0.0 0.15.255.255
50 deny ip any 172.38.0.0 0.0.255.255
60 permit ip 192.168.1.0 0.0.0.255 any

 With this ACL ping works, and data over port 9000 can go into the vlan interface subnet, but there is no reply from the device, even though "Any" should be allowed

Now this is the altered ACL which explicitly allows that traffic over that port. 

Extended IP access list ACL-Block-Stuff-IN
10 permit icmp any any echo
20 permit icmp any any echo-reply
25 permit tcp host 192.168.1.237 eq 9000 host 2.2.2.2
30 deny ip any 10.0.0.0 0.0.0.255 
40 deny ip any 172.16.0.0 0.15.255.255
50 deny ip any 172.38.0.0 0.0.255.255
60 permit ip 192.168.1.0 0.0.0.255 any

This of course, works. I've dumbed down the ACLs quite a bit and provided fake IPs but this is generally what they look like. I know why the second works. There is an explicit allowance for that IP to reach that host over that port (9000 in this case). 

My confusion and question is why the first doesn't allow for replies even though "192.168.1.0/24" is allowed to reach "ANY" IP under on line 60. Shouldn't data flow to and from it freely (sans the previous deny statements) with that command? I'm confused why it does not, but when I explicitly allow it, it works. 

I know this seems like a basic ACL question but its one of those things that some clarity would help a great deal on. Thank you. 

[MHM Cisco World]

25 permit tcp host 192.168.1.237 eq 9000 host 2.2.2.2

I think the server is use 9000 not the client and the client use unknown port, 
so you need to change the port form be source to be destination

[John Robinson IV · Accepted solution]

No, it works when like this. However, I found the issue. It actually turned out to be something so silly. 

there is a deny for the private addresses in the 172.16.x.x range

the original IPs actually has a 170.30.x.x. IP (not the made up 2.2.2.2 I used for this example). I overlooked that the 170.30.x.x falls in the private IP range that is denied, which is why the second one worked (notice that the statement is above the denies)

For shame. 

[MHM Cisco World]

Glad your issue solve.