cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2349
Views
10
Helpful
3
Replies

FTD 1010 same security interface traffic issue

Hi everyone,

I’m having a strange issue with a new FirePower Threat defense installation

 

My Company has an MPLS that connect all the branch offices and an Internet connection for Internet Navigation

 

The FTD is configured in routed mode just to protect Internet traffic  

 

The FTD is the default gateway for the inside network and has IP 192.168.1.1

All the traffic directed to the branch offices is routed trough the router managed by the provider and forwarded by the FTD to IP address 192.168.1.254

 

I defined a static route on the FTD for inside interface and network 192.168.2.0/24 (one of the branch offices)

 

I can ping the hosts located at the remote site but when I try to open a web interface of a device (ie a printer) the browser returns a connection time out error. The same occurs when a client try to reach our internal application server

If I insert a static route on my PC pointing directly to 192.168.1.254 as a next hop for the 192.168.2.0 network everything works fine. So is something related to the FTD configuration.

 

I created an access policy allowing traffic from inside interface to inside interface any any networks

 

 

FTD 1010 6.5.0.4

Interfaces 

ethernet 1/1 outside WAN routed IP x.x.x.x

ethernet 1/3 switched connected to inside cable in vlan 1

Vlan 1 IP address 192.168.1.1

I read that on FTD the traffic between same security interfaces is allowed by default. 

I will appreciate any suggestion

Regards

Claudio

1 Accepted Solution

Accepted Solutions

I think what is happening here is that the traffic sent by the local clients goes one way, and the return traffic goes another. Let's take this example with these two clients, client A (192.168.1.10) and client B (192.168.2.10). When the client A wants to reach the client B on a TCP port, the client A sends its first TCP packet (SYN) to the FTD as its default gateway, the FTD then routes this traffic to the MPLS router connected to the inside segment. The MPLS router then routes the traffic to the client B.

Now, when the client B responds back with the SYN-ACK packet, this packet will not pass through the FTD. Instead, it will be routed directly by the MPLS router, that's because the MPLS router is connected to the same subnet where client A is located. When the client A receives the SYN-ACK from the client B, the client A responds back with the ACK packet. This again, will be sent to the FTD.

At this point, the FTD will drop that traffic. The reason behind this is because from the FTD perspective, it would have only seen the SYN, and the ACK packets sent by the client A, but it has never seen the SYN-ACK packet that was sent by the client B. Therefore, the FTD will drop this traffic as it does not have a complete 3-Way handshake messages, therefore the FTD considers this as an attack and drops it.

To fix this issue, you need to implement a TCP State Bypass policy. To do this on the FTD you need to use FlexConfig, take a look at the Cisco documentation link below, and also at the link of my blog post that would also help.

You might be wondering why ICMP traffic worked?!, one big difference between the TCP traffic and the ICMP is that the ICMP packets are independent, which means the echo requests that the client A sends have nothing to do with the echo replies that will be received from the client B. Also, the ICMP echo requests and replies have not 3-Way handshake, which means once the client A receives the echo-reply from the client B, there are not more packets to be sent from client A to B. So the FTD won't be expecting any more messages for the ICMP flows.

 

https://bluenetsec.com/asa-tcp-state-bypass/

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/211628-FTD-How-to-enable-TCP-State-Bypass-Conf.html

 

View solution in original post

3 Replies 3

I think what is happening here is that the traffic sent by the local clients goes one way, and the return traffic goes another. Let's take this example with these two clients, client A (192.168.1.10) and client B (192.168.2.10). When the client A wants to reach the client B on a TCP port, the client A sends its first TCP packet (SYN) to the FTD as its default gateway, the FTD then routes this traffic to the MPLS router connected to the inside segment. The MPLS router then routes the traffic to the client B.

Now, when the client B responds back with the SYN-ACK packet, this packet will not pass through the FTD. Instead, it will be routed directly by the MPLS router, that's because the MPLS router is connected to the same subnet where client A is located. When the client A receives the SYN-ACK from the client B, the client A responds back with the ACK packet. This again, will be sent to the FTD.

At this point, the FTD will drop that traffic. The reason behind this is because from the FTD perspective, it would have only seen the SYN, and the ACK packets sent by the client A, but it has never seen the SYN-ACK packet that was sent by the client B. Therefore, the FTD will drop this traffic as it does not have a complete 3-Way handshake messages, therefore the FTD considers this as an attack and drops it.

To fix this issue, you need to implement a TCP State Bypass policy. To do this on the FTD you need to use FlexConfig, take a look at the Cisco documentation link below, and also at the link of my blog post that would also help.

You might be wondering why ICMP traffic worked?!, one big difference between the TCP traffic and the ICMP is that the ICMP packets are independent, which means the echo requests that the client A sends have nothing to do with the echo replies that will be received from the client B. Also, the ICMP echo requests and replies have not 3-Way handshake, which means once the client A receives the echo-reply from the client B, there are not more packets to be sent from client A to B. So the FTD won't be expecting any more messages for the ICMP flows.

 

https://bluenetsec.com/asa-tcp-state-bypass/

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/211628-FTD-How-to-enable-TCP-State-Bypass-Conf.html

 

Thank you Aref you got the point!
This is obviously a problem of asymmetric routing and your post blog was really helpful

Since I’m using 6.5 I implemented the Bypass policy according to this guide rather than using flexconfig

https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/threat_defense_service_policies.html#id_71072

 

Thanks a lot !

Claudio

 

You welcome, Claudio, glad to know that was useful, and it is awesome to know that you could create the policy through UI.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: