Some office mode traffic dropped due to anti spoof

[Ruan_Kotze]

Hi All,

I have a scenario whereby only some traffic from office mode IP's is being dropped by antispoof.

Symptoms:

Some connection from the client works fine, e.g. DNS traffic, https intranet etc.  Some traffic however is being dropped, with anti spoofing on the external interface given as the reason.  Specifically, the traffic being dropped is RADmin.  The other observation is that all allowed traffic shows up as being encrypted in the RemoteAccess community, whereas the dropped traffic does not.  In all cases the source IP is the same.  All was working until about two weeks ago, with no apparent changes done.

 What I have verified:

• Back Connections enabled
• NAT disabled to / from Office mode IPs
• Office-Mode anti spoofing enabled
• Office-mode IPs are excluded from external interface anti spoof

The one red flag is that for this specific user the gateway is handing out an IP address that is included in the gateway's encryption domain (via ipassignment.conf).

Environment is running R80.30 take 191.

Any pointers would be appreciated.

Ruan

[Timothy_Hall]

Office Mode addresses assigned to Remote Access clients should not appear in the VPN Domain of the firewall.  However you can work around this by going to the Topology Settings screen of the external interface, checking the Antispoofing box "Don't check packets from", and then put in the Office Mode IP block(s).

[Ruan_Kotze]

Hi Timothy,

Thanks for your response, very satisfied buyer of both your books! 

We did exclude the OM IP's on the external interface.  The intriguing thing is that only *some* traffic from the client is dropped.

Regards,
Ruan

[Timothy_Hall]

Please provide the redacted log card, is it inbound antispoofing or outbound antispoofing that is dropping it?

[Ruan_Kotze]

Hi Timothy,

Apologies for the delayed response.

It's inbound antispoofing that's dropping the traffic, on the external interface of the gateway.  Host 172.16.100.109 is the OM IP, 172.16.200.222 is the internal host.

The traffic that is being dropped by AS is replies to traffic originating from inside.  If I do a unsolicited connection from the OM IP to inside, it works fine.

Below is one of the AS logs:

Time:                    2020-05-18T07:26:39Z

Interface Direction:     inbound

Interface Name:          eth7

Id Generated By Indexer: false

First:                   true

Sequencenum:             245

Source:                  172.16.100.109

Source Port:             4899

Destination:             172.16.200.222

Destination Port:        53637

IP Protocol:             6

Message Information:     Address spoofing

Session ID:              0

Destination Machine Name:172.16.200.222

Action:                  Drop

Type:                    Log

Policy Date:             2020-05-18T07:12:00Z

Blade:                   Firewall

Origin:                  xxxx

Service:                 TCP/53637

Product Family:          Access

Interface:               eth7

Description:             TCP/53637 Traffic Dropped from xxxx (172.16.100.109) to xxxx (172.16.200.222)

Thanks,
Ruan

[Timothy_Hall]

Do you have an automatic Hide NAT defined for the 172.16.100.0/24 object or whatever the OM IP range is?

I'm suspecting you may have something else wrong that is keeping this specific connectivity from working beyond just your antispoofing drops, which may only be a symptom.  If you disable gateway antispoofing enforcement "on the fly" as detailed in the article below, do those connections start working?  My guess is they won't...

https://community.checkpoint.com/t5/Access-Control-Products/can-anyone-tell-me-the-correct-command-t...

[Ruan_Kotze]

Hi Timothy,

No NAT taking place to / from OM ranges, verified this multiple times.  

If I disable anti-spoofing on either the external interface or even just within the cluster object's VPN clients settings traffic flows normally and as expected (disabling either one of the two causes traffic to flow).

Has to be said, I've implemented this multiple times without issue, and I also did a similiar test in my lab over the weekend just to see if it's perhaps an issue with Take 191 - but worked perfectly.  Will escalate to TAC tomorrow.

Thanks for taking the time to respond, much appreciated!

Thanks,
Ruan

[Juan_]

Hi Ruan,

I'm facing something similar. What was the fix for you in the end?

Regards

[Ruan_Kotze]

It boiled down to two things for us, either disable anti-spoofing on in the cluster object's VPN clients settings or hand out a OM IP range that did not overlap with the encryption domain. We changed the OM IP range, that seemed the better way to go long-term.