topic Re: FMC S2S VPN Return traffic ports flipping and hitting block rule in Network Security

FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Thu, 11 Jul 2024 09:53:58 GMT

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!

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

tvotna — Thu, 11 Jul 2024 10:40:58 GMT

@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

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MHM Cisco World — Thu, 11 Jul 2024 12:28:12 GMT

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

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Wed, 17 Jul 2024 15:24:27 GMT

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!

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MHM Cisco World — Thu, 18 Jul 2024 09:57:18 GMT

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

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

tvotna — Thu, 18 Jul 2024 08:32:26 GMT

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.

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Thu, 18 Jul 2024 08:35:51 GMT

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?

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Thu, 18 Jul 2024 08:49:29 GMT

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?

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

tvotna — Thu, 18 Jul 2024 08:55:30 GMT

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

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Thu, 18 Jul 2024 10:00:42 GMT

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.

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MHM Cisco World — Thu, 18 Jul 2024 10:01:56 GMT

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

Re: FMC S2S VPN Return traffic ports flipping and hitting block rule

MynameisGeoff — Thu, 18 Jul 2024 10:09:03 GMT

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.