Inter Vlan ACL Logic help

[irusev27]

Here is the thing.
I have 1 Multilayer Switch. On that multillayer switch I have Vlan 80 (Ip 192.168.99.254) and Vlan 100 (Ip 192.168.100.254)
I have Cato Device that provides access to the internet Plugged in to an access port in the multilayer switch that belong to vlan 100. The Ip for that Cato Device is 192.168.100.4
Multilayer switch have ip routing enabled. Multilayer switch have one static ip route injected into its RIB 0.0.0.0 0.0.0. 192.168.100.4

I have one device inside Vlan 80 a computer with ip address 192.168.99.10 255.255.255.0 Default Gateway 192.168.99.254 (vlan 80 SVI).

I created a ACL Extended:
Deny ip 192.168.99.0 0.0.0.255 192.168.100.0 0.0.0.255
Permit ip any any
I apply that ACL to interface Vlan 80 in inbound direction.
The end result is that Host in vlan 80 with ip 192.168.99.10 cannot ping or reach anything on 192.168.100.0 networks BUT it can go on the internet ( That means it is reaching 192.168.100.4 that belongs to vlan 100) This gets me a little confused.

My logic here is that the ACL do block access to the 192.168.100.0 subnet, However the ACL does not block access from the host to its default gateway 192.168.99.254. So the host can reach its default gateway hence bypassing the ACL and the Multilayer switch then routes the traffic to Cato Appliance in vlan 100 because it has  0.0.0.0 0.0.0.0 192.168.100.4 route. Am I correct in my logic ?
Also how can I create an ACL with permit insdead of deny to reach the internet only ?

[Flavio Miranda · Accepted solution]

@irusev27 

 Not bypassing. It is working as expected.

For traffic leaving toward the internet, the source IP address will be 192.168.99.10/24 and the destination is the IP address on the internet, which will be discovered by using DNS resolution. But, surelly will not be the network 192.168.100.0. Which means, your statement  "Deny ip 192.168.99.0 0.0.0.255 192.168.100.0 0.0.0.255" will not match when going to internet.

 Only the traffic sent toward  network 192.168.100.0 0.0.0.255 will have a match and will be denied.

"Am I correct in my logic ?"

Nop.

"Also how can I create an ACL with permit insdead of deny to reach the internet only ?"

If I understood correctly you have reached your goal, dont you? With that ACL you can reach the internet but not the host on vlan 100.

Usually you dont permit traffic toward the internet as we dont know what will be the IP address as the option is infinit. You leave it as permit ip any any, just like you did and we deny what we know which is the internal subnets.

[irusev27]

Flavio you have made Networking Great Again ! Thank for the clear explanation, this makes perfect sens, the answers were there all along, its just poor fundamentals on my side. Now I feel very confident creating ACL's and especially guest networks with acess to the internet only.

To asnwer your question yes that ACL has reached my goal, but how I got there was very comical and an emberrasing... (Story for another time...) Also Thanks for clarifying why we dont use permit (Whitelisting) statement for internet access. Now I understand why when i was trying to use only permit to my gateway and dns did not work..... the DNS translation will resulted with a packet with destination IP of the website and before it hits the Interface Vlan 80 (Default Gateway) the ACL will stop it....

[paul driver]

Hello
Try adding this yo you ACL

ip access-list extended x
5 permit  ip 192.168.99.0 0.0.0.255 host 192.168.100.4

[paul driver]

Hello @irusev27 
Apologies I misread your OP regards the acl, 

After re-reading this op @Flavio Miranda  is correct , If that access-list that is negating vlan 100 traffic is applied on vlan 80 svi it wont negate communication from internet traffic to any host in vlan 80 because internet traffic is not originating to/from vlan100, as far as vlan 80 hosts are concerned internet traffic is coming for their own default-gateway ip address, as such the communication still worked successfully but this is due initially to arp resolution and the rtr having rib/fib entry's for the default next hop.

The internal host will send an arp request for a external network host towards its own default-gateway, (the rtr or l3 switch)  which will have a default route externally and no doubt nat, it will perform a rib/fib lookup sees it has a path to the external network,  it will then reply back to internal vlan 80 hosts with an arp unicast with its own ip address as the source address (which is the internal hosts default-gateway), Now the internal hosts will now know the dst mac/ip of their own default gateway and any external traffic can be forward to the rtr and then on onwards.

Now being a bit pedantic for a moment as you can see above so you could even go as far and say DNS resolution really isn't necessary for successful communication if just the ip address is being used but that is very rare nowadays so its a must.