FMC S2S VPN Return traffic ports flipping and hitting block rule

[MynameisGeoff]

Hi All, 

Wondering if I could get your take on something and if I've got a misconfiguration in the deployment somewhere? 

We have some FTD's managed by FMC.

We have live VPN tunnels and we've been using the mandatory ACP area to define the access rules for the VPN. We have used the auto NAT exempt feature within the S2S VPN profile, but haven't used the Sysopt-permit feature to allow VPN filters, as it doesn't support Port Groups, so managing some of the rulesets for the VPNs would become a pain.

Looking through the unified events, everything looks good and the traffic is hitting the defined rules, but occasionally I am seeing return traffic where the port has flipped to a source port and then that's being blocked?? We've only ever built rules specifying destination ports, so this is confusing me. 

Can anyone think what could be causing this??

Thank you!

[tvotna]

@MynameisGeoff If I read your message correctly, you do use "sysopt permit-vpn" on FTD bypassing access control for VPN traffic. I remember that somebody reported that unlike ASA OS, FTD applies this setting unidirectionally for inbound traffic only: https://community.cisco.com/t5/vpn/ftd-site-to-site-vpn-seems-to-ignore-bypass-acp-setting/td-p/4953947

I didn't test myself.

HTH

[MHM Cisco World]

Sorry I don't full get your issue here 

HostA send traffic from portA to hostB portB

The hostB sure will use reply by portB to portA of HostA 

ACL must check one direction and return traffic must bypass any ACL since conn is there.

Can you more elaborate 

MHM

[MynameisGeoff]

Hi All, 

Sure, let me explain a bit better. So we have a functioning VPN with Live traffic flowing. I haven't heard of any issues yet, but watching the logs within the Event Viewer, occasionally I see some strange logs like I showed in the image attached to the first post. This isn't happening all the time, but I'm seeing it frequently enough to be concerned, as this may cause issues later down the line.

The VPN Profile is fairly straight forward:

It's a Policy Based (Crypto Map) VPN.

We are using the Auto No NAT feature when creating the VPN profile - "Exempt VPN traffic from network address translation"

No Filter applied to the VPN with all rules defined within the Global ACP list, so we are not using the sysopt permit-vpn feature.

The access policy has been configured defining allow traffic to destination ports, but as a combined rule. (Will link a screenshot of this)

Testing with the packet tracer the times I've tested show the expected results on the times I've tested, so very confused.

Thanks all for your support and interest!

[MHM Cisco World]

Friend you need 

ACL from OUT into IN 

ACL from IN into OUT 

I see you config only one ACL for both direction so sure if remote VPN try to access any resource internal then traffic will drop.

MHM

[MynameisGeoff]

Hi Cisco World,

Not exactly, I've included everything into one line. But maybe doing like this could cause issues in the flow??

How it's configured::

Source Zone: Both Inside & Outside
Source Networks: Both Source and Destination Networks (Defined in VPN interesting Traffic)
Source Ports: ANY
Destination Zone: Both Inside & Outside
Destination Networks: Both Source and Destination Networks (Defined in VPN interesting Traffic)
Destination Ports: Defined Ports for VPN

There's no reason I couldn't separate the rule into two; having a single rule for Inbound traffic and another for Outbound traffic, but I didn't think this was required?

[MHM Cisco World]

Friend ypu use one line for both zone and ypu use destiantion port not source port.

My suggestion is separate this ACL into two line 

Inside to outside and use l4 port of  remote LAN server as destiantion 

Outside to inside and use l4 port of local LAN server as destiantion 

You can use one acl both directions if you use subnet only but use l4 port make acl direcional aware and this drop your traffic 

MHM

[MynameisGeoff]

Thanks for this input Cisco World, I will also split the ACL into 2 separate rules to see if the behaviour changes.

Just for transparency, it will look something like the screenshot attached.

[tvotna]

Ok. In this case the blocked packet can be a TCP RST packet sent by host A after the connection was torn down by host B (or something like that). You can collect capture on the inside interface to verify this theory.

[MynameisGeoff]

Ok... That is interesting!

And this may happen only occasionally and be represented in the logs with the destination port flipping to a source port? Similarly to the screenshot in my original post?

[tvotna]

Yes, this is a new connection request from firewall point of view.

[MynameisGeoff]

Ok right, I'll start trying to capture some of this!

Thanks all for your help so far trying to figure out what's happening here, really appreciate the support.