Cisco FTD blocking inside traffic

[Arild Andersen]

In our test environment we have tried activate our Cisco FTD 6.2.2.1, but we have one reoccurring problem, the FTD keeps blocking traffic that goes between hosts on the same inside network. When we check the connection log we see that it hits the "Default Action, Monitor Policy"rule. We have also tried to enable a Trust and allow between inside (source) and inside (destination), but it still block the traffic with Default Action as mentioned above.

And as a last resort we tried to add a Prefilter rule with Fastpath to make sure that the FTD does not inspect traffic on the inside network, but still same result as above.

Anyone got some tips to what Im doing wrong or what I should check?

[Marvin Rhoads]

That's certainly odd. You do have your default IPS policy set for something like "Balanced Security and Connectivity" (vs. block all traffic) right?

What does packet-tracer tell you? e.g.:

 packet-tracer input inside tcp <some inside host address> 1025 <some other inside host address> 80 detailed

[Arild Andersen]

Shouldnt the "Default Action" be set to "Acccess Control: Block All Traffic" since if not hits any of the rules above I want the traffic to be blocked? I have rules above that have "Allow" on that traffic I want to be allowed, but it seems like it ignore those rules and go straight for "Default Action".
Sorry, dont have possibility to run packet-trace atm.

[Marius Gunnerud]

Default action block all traffic is fine.

• are these two hosts on the same subnet or on different subnets located on the same FTD "inside" interface?
• How are you accessing the host? using IP or URL?

[Arild Andersen]

- They are located on the same subnet and the same security zone
- Both IP and URL, but majority is URL. I also seen DNS traffic beeing blocked

[Marius Gunnerud]

Is the FTD set up in transparent mode?

could you please describe your physical setup.

If these are on the same subnet and are connected to an external switch then this is very odd behavior.

[Arild Andersen]

Ok, I will come back with more information

[Arild Andersen]

The FTD is blocking traffic sent between internal hosts.
Have runned wireshark, does not see any odd traffic (not much at all)
Its a flat network so the two gateways have different IP in the same network.
FTD is running in routed mode.

It seems that traffic between internal host is seen by the FTD and it is sending out block packets because it does not see any session setup and therefore is hitting default action.

Two external consulents have check FTD config without seeing any errors.
All best practises for VMware and FTD setup is in place.

Her is a quick drawing of the network:

[Marius Gunnerud]

this seems to be asynchronous routing that is causing this issue.  Can you set up capture on both ASA's and see where the traffic is going?

[Arild Andersen]

Hi,

We did some research on asynchronous routing and we found this document, which explain that we can use TCP State Bypass using FlexConfig to resolve asymmetric routing. Is this a sugested solution to the problem you described or is there another place in the configuration where we should look?

Since the firewalls isnt online now I cant do capture of the traffic at the moment.

[Ajay Saini]

Hello,

TCP-state-bypass would be one way of doing it. Since this is asymetric routing and firewall expects bidirectional traffic to be seen before allowing.

Another way this can work is to NAT the source ip addresses of host A to the FTD inside interface ip so that the other host B(lets say) would be forced to send the traffic back through the firewall and hence firewall would see both ways traffic. ofcourse, we will have to allow same-security-traffic permit intra interface.

HTH,

AJ

[Marvin Rhoads]

Fix the architecture so that packet flow is proper before resorting to obscure features designed for really unusual use cases.

Anytime you consider implementing something like TCP state bypass or unusual NAT you should pause and think carefully about why you are doing that in the first place.

What's your goal for this setup and is there an easier more straightforward way to accomplish it? If you explain the former we may be better able to help with the latter.

[Arild Andersen]

Hello,

I totaly agree that the architecture should be fixed and work as inteden instead of resolving to other things. But we have researched the documentation we could find (get a impression that the system is not very good documented yet) and we have had two external consulents to look at the setup and they couldnt find anything wrong. Which made us try obscure solutions like Prefilter rule With Fastpath and TCP State Bypass which is something we rather not want to. I just want to underline that we done a lot of research and trying/failing before coming to this forum.

If you look at the picture above in this thread you can see that we have two firewalls, which at the moment is two Cisco vASA, now we want to switch out GW #2 with a vFTD for increased security. When we did the setup for the vFTD did mostly copy the setup from the old vASA and modified where needed. The strangest problem that occour is that traffic that is supposed to go trough GW #1 get blocked by the vFTD, which is traffic that shouldnt be affected by the vFTD at all. Another problem is that the vFTD blocks traffic between hosts on the inside interface which are on the same subnet and security zone.

Edit:

Just want to inform that we only have static routing in this network, each host only have either GW #1 or #2, some of the have routes added if they need to reach a network on the other GW.

[Marvin Rhoads]

I'd also recommend you double check your vSwitch setup. If both the vFTD and ASAv are on the same vSwitch there may be a problem with that configuration.

One other thing to do is packet-capture (use the FMC troubleshooting tool) the blocked traffic and see if you can ascertain why the vFTD is getting it in the first place.

[Arild Andersen]

Hello,

I did a packet trace between host A and host B on the inside network, both on the same subnet and security zone. It gave me the following drop reason:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: dmz365
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-adjacency) No valid adjacency

But this is traffic that shouldnt go trough the vFTD at all since they are on the same subnet. We have a theory about why the vFTD is blocking the traffic; hte vFTD see traffic that is supposed to go trough the vASA but it doesnt have a session for that connection so it blocks it. Would that be a valid assumtion?

Edit:

We found that there is a bug that gives this drop-reason if any NAT rules have Destination Interface Object as "any". But we dont have any NAT rules that fits this condition.