- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi
We have a VSX cluster with a VS for Remote Access. Since our staff now work from home, there is a requirement to allow support staff to use SCCM Remote Control. This is set to connect from an office PC or server out to a Remote Access VPN user.
After trying various things to get this to work, as a last resort I disabled anti-spoofing on the external interface. Once done, RC worked absolutely fine.
Leaving this makes me nervous as everything I know says to always have anti-spoofing enabled. So, does disabling it on one interface potentially open us up to more issues?
Thanks
Roy
Hi @Roy_Smith
I think it's R80.30. I could see these problems with several other gateways. Here the TAC is also involved.
1) Are your office mode addresses of IP spoofing used for internal interfaces? This may also cause this error.
2) Is IP spoofing active for the office mode pool?
3) Or set don't check packets from:
Emergency solution:
From my point of view, change to detect mode of IP spoofing on the external interface is not very security relevant.
Why! All internet IP addresses are allowed here. Private addresses 10.x.x.x, 192.168.x.x, ... are not routed in the internet. If you now drop IP addresses from 224.0.0.0-255.255.255.254, you are reasonably safe. But keep in mind that you have to activate certain multicast IPs (for example HSRP, VRRP,...). But you should also allow 255.255.255.255 in individual cases.
I think the solution is not nice, but you can live with it.
Then you can analyze the issues. The goal should be to enable IP spoofing again.
Maarten
Yes, I have tried putting the VPN subnets in the box and I also tried the internal subnets the VPN clients try to connect with no success. I have messed about with various settings in our anti-spoofing group and encryption domain, again with no success.
Roy
Hi @Roy_Smith
I think it's R80.30. I could see these problems with several other gateways. Here the TAC is also involved.
1) Are your office mode addresses of IP spoofing used for internal interfaces? This may also cause this error.
2) Is IP spoofing active for the office mode pool?
3) Or set don't check packets from:
Emergency solution:
From my point of view, change to detect mode of IP spoofing on the external interface is not very security relevant.
Why! All internet IP addresses are allowed here. Private addresses 10.x.x.x, 192.168.x.x, ... are not routed in the internet. If you now drop IP addresses from 224.0.0.0-255.255.255.254, you are reasonably safe. But keep in mind that you have to activate certain multicast IPs (for example HSRP, VRRP,...). But you should also allow 255.255.255.255 in individual cases.
I think the solution is not nice, but you can live with it.
Then you can analyze the issues. The goal should be to enable IP spoofing again.
Your screenshots helped a lot. It turned out that "Perform anti-spoofing on Office Mode addresses" was enabled. I disabled this and re-enabled "Perform anti-spoofing" on the interface and everything works as we want.
Much happier situation now with anti-spoofing enabled again
Thanks for the help
Roy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 13 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY