ISP facing L3 switch ACL blocking internet

[sanchezeldorado]

Hello,

I'm trying to secure my network. First here's a diagram.

I have a L3 switch for each ISP. For this question, I'll focus on the left switch with the WAN IP of 3.3.3.3. The WAN IP is external facing, so I want to harden it for added security. Specifically, I don't want to allow anything from outside to directly communicate with my switch, and I want to block some ports incoming, but don't block anything outbound. I've applied the ACL below, and ICMP continues working, but TCP stops working. This is a high availability network and I had to revert changes ASAP to bring it back online so I didn't have much time to troubleshoot beyond that. Can anyone tell me why this would happen, and I'm open to suggestions if anyone else would implement this differently. The ACL was applied to the outside (3.3.3.3) interface on the inbound direction.

ip access-list extended acl-ISP1-in
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any unreachable
deny icmp any any
deny tcp any any eq 22
deny tcp any any eq telnet
deny udp any any range netbios-ns netbios-ss
deny tcp any any range 137 139
deny udp any any eq 445
deny tcp any any eq 445
deny udp any any eq 135
deny tcp any any eq 4786
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip host 0.0.0.0 any
deny ip any host 3.3.3.3
deny ip any host 1.1.1.1
permit ip any 1.1.1.0 255.255.255.242
deny ip any any

Thanks!

[MHM Cisco World]

deny ip host 0.0.0.0 any <<- what this ACL ?

can you share 

show ip access-list 

[sanchezeldorado]

Per Mikael's response, "host" 0.0.0.0 is only one IP address, and from my understanding it can prevent some types of attack. I don't know much more than that.

[MHM Cisco World]

Yes I check this can add for security to deny 0.0.0.0 host. 

[mlund]

Hi

The last entry

deny ip any any

is why everything stops, if it is not previously permitted. I suppose you should have

permit ip any any

instead.

@MHM

The entry

deny ip host 0.0.0.0 any

is only denying packets where the source is set to 0.0.0.0.

/Mikael

[sanchezeldorado]

Hi Mikael,

Thanks for the response. The

deny ip any any

may be the cause, but I don't want to

permit ip any any

My goal is to allow any traffic that is destined to my subnet block, but nothing else. All of my outbound traffic would be natted by my firewall and coming from 1.1.1.4. Therefore any returning traffic should be hitting

permit ip any 1.1.1.0 255.255.255.242

before the deny all rule. That should include traffic initiated from the inside as well as from the outside. Is that incorrect? I suppose I could do a permit any any at the end since I'm blocking RFC1918 addresses already, but now I'm curious why the current config would block my traffic.

[MHM Cisco World · Accepted solution]

friend still I need to see

show ip access-list

 
I need to see where the highest match number 

also ACL done before NAT so you need to add real IP not map IP to acl. 

[sanchezeldorado · Accepted solution]

I am not using NAT, but while looking at the access-list, I realize I'm a complete idiot. I entered the line

permit ip any 1.1.1.0 255.255.255.242

without a wildcard mask. It translated it to "0.0.0.0 255.255.255.224". I'm sure that adding it as "1.1.1.0 0.0.0.15" will solve my issue. 255.255.255.242 wasn't even a valid subnet mask. Thank you for your help on this.

[MHM Cisco World]

You are so so welcome 

[paul.driver]

Hello
You could use various methods, to name a few, Hardware firewall, IOS fw (ZBFW), Context-Based Access (CBAC) , Reflective access lists etc.. Thus to allow traffic exteranlly that is initiated from the Lan but negate any external traffic incitation you don’t wish to allow.

Belwo is an example of a Reflective acl, which is allowing ICMP but negating any other external traffic from being initiated towards your wan rtr, if you want to allow some other traffic then amend the Ingress acl to accommodate such.

Reflective acl
ip reflexive-list timeout 180

ip access-list extended Ingress
permit icmp any any
evaluate TRAFFIC

ip access-list extended Egress
permit ip any any any reflect TRAFFIC
permit icmp any any reflect TRAFFIC




Int x/x/
Description WAN
ip access-group Ingress in
ip access-group Egress out

[sanchezeldorado]

Thanks Paul. These switches are outside of my firewall, and the purpose is to block some basic ports and IPs BEFORE they get to my firewall. Due to my firepower application rules, some ports are showing as open on vulnerability scans, so I'm shutting them before they reach my firewall. Also my catalyst switch doesn't support connection tracking. I would think that my current ACL allowing all traffic to my firewall's IP would apply to traffic initiated from the inside OR the outside. I'm trying to get a maintenance window for tonight to test further.

[paul.driver]

Hello
Given your OP pertaining the topology, it looks like those switches are being used as L2 Wan Handoff nodes with the firewall facing the internet/ISP wan connections and the wan rtrs situated behind the fws?
Now by default as firepower(s) are stateful they should not allow wan initiated traffic internally unless you allow it, and even if you have ports open on the wan rtrs they are located behind the Fws so you just need to create a rule set on the fws to negate connection to/from the wan rtrs specific to the ports you wish to block, So im not sure why you would require an acl on the switches.  

Apologies if I have misinterpreted your topology?

[paul driver]

Hello
 your OP pertaining the topology, it looks like those switches are being used as L2 Wan Handoff nodes with the firewall facing the internet/ISP wan connections and the wan rtrs situated behind the fws?
Now by default as firepower(s) are stateful they should not allow wan initiated traffic internally unless you allow it, and even if you have ports open on the wan rtrs they are located behind the Fws so you just need to create a rule set on the fws to negate connection to/from the wan rtrs specific to the ports you wish to block, So im not sure why you would require an acl on the switches.  

Apologies if I have misinterpreted your topology?

[sanchezeldorado]

Hey Paul,

Regarding my topology:
1. I'm using Layer 3 switches NOT Layer 2 for the handoff.
2. My ISP gives me a /30 for the outside of my Layer 3 switch. I then route that to the inside of my switch to my public /27 block of IPs.
3. My SDWAN routers AND my firewall are behind the Layer 3 switch using public IPs.

Regarding my firewall, when you use application rules on an FTD firewall, the firewall has to pass a few packets of the TCP negotiation before it can identify the application traffic and block it. The TCP session is never actually established, and traffic isn't actually allowed, but vulnerability scanners see it as an open port because the first packet gets a tcp establishment reply. Or something close to that. I'm not increasing security by blocking the ports, I'm simply preventing the vulnerability scanners from thinking that the ports are open.

See my other reply about the solution to this ticket and thanks for your time on this.

[paul driver]

Hell
You could use various methods, to name a few, Hardware firewall, IOS fw (ZBFW), Context-Based Access (CBAC) , Reflective access lists etc.. Thus to allow traffic exteranlly that is initiated from the Lan but negate any external traffic incitation you don’t wish to allow.

Belwo is an example of a Reflective acl, which is allowing ICMP but negating any other external traffic from being initiated towards your wan rtr, if you want to allow some other traffic then amend the Ingress acl to accommodate such.

Reflective acl
ip reflexive-list timeout 180

ip access-list extended Ingress
permit icmp any any
evaluate TRAFFIC

ip access-list extended Egress
permit ip any any any reflect TRAFFIC
permit icmp any any reflect TRAFFIC




Int x/x/
Description WAN
ip access-group Ingress in
ip access-group Egress out