- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
In the list of limitations of SD-WAN, we see this:
"PMTR-104986: For inbound connections from the internet, SD-WAN does not support the symmetric return of packets through the same interface on which the connection was originally received, in case of multiple ISPs.
The return will be determined based on the OS routes."
That seems like a very basic limitation. and a step back since it is even supported in ISP redundancy, which was already a very archaic feature.
This means that differently from IPS redundancy, which returns packets through the same interface the connection was received, SD-WAN will route traffic through the prefered OS route. Thus, you cannot have a server published through more than one isp link and one inbound NAT rule for each isp link, it will only work through one link.
The methods I found to deal with this are:
I'm interested to know how other people in this forum are dealing with this. Does everyone have load balancers for inbound connections? Am I missing something?
Hi,
Indeed, this is basic limitation.
We already have the fix for it. So the return (s2c) packets will be routed back from the same ISP the connection (c2s) originally came through.
it should be merged into JHF that will be released in the next month or so for GAIA.
As a temp workaround:
If you need the redundancy to the server works as active/backup, you can just set two default routes on your GAIA with different priorities, with "IP Reachability Detection" configured (if you want to probe the line. Otherwise just with "ping on"). So once main line is dead, the active route would be the second ISP, and then the server would be accesible through it.
In case you need it to be accesible in parallel via multiple ISPs, i afraid only your PBR idea can work.
Let me know if you need further assistance,
i would like to update that the mentioned feature is now available on GAIA GWs from R81.20 JHF 79 that was released.
in order to enable this feature after installing this JHF:
until we will make it enabled by default, it's needed to edit (or create) the file: $FWDIR/conf/sdwan/sdwan_steering_params.json
and add this line to the file:
{ "sdw_default_symmetric_return_value" : true }
then restart the steering process:
sdwan_steering_stop;sdwan_steering_start
Thanks
Hi,
Indeed, this is basic limitation.
We already have the fix for it. So the return (s2c) packets will be routed back from the same ISP the connection (c2s) originally came through.
it should be merged into JHF that will be released in the next month or so for GAIA.
As a temp workaround:
If you need the redundancy to the server works as active/backup, you can just set two default routes on your GAIA with different priorities, with "IP Reachability Detection" configured (if you want to probe the line. Otherwise just with "ping on"). So once main line is dead, the active route would be the second ISP, and then the server would be accesible through it.
In case you need it to be accesible in parallel via multiple ISPs, i afraid only your PBR idea can work.
Let me know if you need further assistance,
Hi Amir,
Thank you for the information. That's great news!
You are welcome
i would like to update that the mentioned feature is now available on GAIA GWs from R81.20 JHF 79 that was released.
in order to enable this feature after installing this JHF:
until we will make it enabled by default, it's needed to edit (or create) the file: $FWDIR/conf/sdwan/sdwan_steering_params.json
and add this line to the file:
{ "sdw_default_symmetric_return_value" : true }
then restart the steering process:
sdwan_steering_stop;sdwan_steering_start
Thanks
Hi Amir,
Thank you for the information!
I installed this JHF, but after that I'm unable to push the SD-WAN policy. It shows the following error:
“Failed to enforce new policy. Reason: Failed to lower support_fec flag(Return code: 10)”
Any ideas about what support_fec flag is?
I'm running a PoC of this feature, so I'm unable to open a ticket with TAC about this.
I'm aware that this take is ongoing and there might be issues.
it's related to the new fec feature that also comes with that JHF.
This issue is currently under investigation. either open TAC or DM me to get updates on this.
Thanks
Just to update everyone reading this thread:
We found an issue with GAIA GWs working in Kernel Space firewall (KSFW) on JHF 79 running SD-WAN.
The issue would result in a SD-WAN policy enforce failure with the following message:
“Failed to enforce new policy. Reason: Failed to lower support_fec flag(Return code: 10)”
If you have any GAIA GW with SD-WAN Enabled which running as Kernel space firewall (usually open servers, or cloud GWs), please avoid upgrading to JHF 79 for now until further notice.
We already have the HOTFIX for that which should be released very soon (probably tomorrow) as a HF or as a new JHF, and once it’s there I will send an update with the details.
Feel free to ask me here or on DM if needed.
Thanks,
Hello,
The fix to the policy enforcement issue above ("Failed to lower support_fec flag") for Kernel Space Firewall mode, is now available in JHF 84 that was released today.
https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Take_84.htm?tocpath=_____6
if for any reason, you need the fix as a small hotfix on top of JHF 79, please contact me directly.
Thanks
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY