vpn issue since R80.10 - Check Point to Fortigate (behind NAT router)

[Tom_Coussement]

We are having problems with some vpn tunnels since we upgraded our firewall gateway to R80.10 (previous R77.30)

More specifically between our Check Point R80.10 gateway and Fortigate gateways that are behind a NAT router.

Behaviour:

On both firewalls tunnel status is shown as up.

When sending traffic from LAN behind Check Point to LAN behind FortiGate, the traffic arrives at the host behind the FortiGate. The answer is send, can be seen on the FortiGate but doesn't arive at the original sending host.

With tcpdump on Check Point we only see syn from src to dst, no ack from dst to src.

No drops between src and dst with fw ctl zdebug + drop

We do see drops with fw ctl zdebug + drop for communication between the 2 wan ip addresses

;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=17 (public ip on NAT router):4500 -> (public ip on Check Point):0 dropped by asm_stateless_verifier Reason: UDP src/dst port 0;

 And after a few of the messages above:

;[cpu_0];[fw4_0];fw_log_drop_conn: Packet <dir 1, (public ip on NAT router):4500 -> (public ip on Check Point):4500 IPP 17>, dropped by do_inbound, Reason: decryption failed;

In the logs:

Time: 2017-11-08T13:44:57Z
Interface Direction: inbound
Interface Name: eth2
Id: ac140a8b-8490-5309-5a03-0a598eb10000
Sequencenum: 3
Protection Name: Packet Sanity
Severity: Medium
Confidence Level: High
Protection ID: PacketSanity
Performance Impact: Very Low
Industry Reference: CAN-2002-1071
Protection Type: Protocol Anomaly
Information: Invalid UDP packet - source / destination port 0
Name: Malformed Packet
Source Country: Belgium
Source: (public ip on NAT router)
Source Port: 4500
Destination Country: Belgium
Destination: (public ip on Check Point)
Destination Port: 0
IP Protocol: 17
Action: Drop
Type: Log
Policy Name: Standard_Simplified
Policy Management: firewall
Db Tag: {F56DAD90-0D6A-2D4B-B024-FD57071DC021}
Policy Date: 2017-11-08T13:41:10Z
Blade: Firewall
Origin: xxxxxxxxx
Service: UDP/0
Product Family: Access
Logid: 65537
Marker: @A@@B@1510095600@C@2064729
Log Server Origin: xxx.xxx.xxx.xxx
Orig Log Server Ip: xxx.xxx.xxx.xxx
Inspection Settings Log:true
Lastupdatetime: 1510148697000
Lastupdateseqnum: 3
Rounded Sent Bytes: 0
Rounded Bytes: 0
Stored: true
Rounded Received Bytes: 0
Interface: eth2
Description: UDP/0 Traffic Dropped from (public ip on NAT router) to (public ip on Check Point) due to Invalid UDP packet - source / destination port 0
Profile: Go to profile

We opened a ticket with both Check Point & Fortigate but seems like they don't find a sollution and point to each other...

I know that a vpn with a firewall behind a NAT router is not the best sollution, certainly for vpn between 2 vendors, so we try to avoid such setups but sometimes there is no other option.

Anyone else who experienced such problems with R80.10?

Suggestions?

[Vladimir]

Can you tell me if the external interface of the fortigate belongs to its encryption domain (as it is defined in Check Point) and if you have tried the "Disable NAT inside VPN community" option in the Community properties?

[Tom_Coussement]

We tried with "Disable NAT inside VPN community" option checked and unchecked.

The private ip range that is configured on the WAN interface of the Fortigate is not in the vpn domain on the interoperable device that is configured on the Check Point fw

[Vladimir]

How about:

To configure NAT-T for site-to-site VPN:

1. Open the Gateway Properties of a gateway that has IPsec VPN enabled.
2. Select IPsec VPN > VPN Advanced.
3. Make sure that Support NAT traversal (applies to Remote Access and Site to Site connections) is selected.

   NAT-Traversal is enabled by default when a NAT device is detected.

[Tom_Coussement]

🙂 This option is enabled.

It must be something R80.10 specific I think as it worked with R77.30 before.

[Vladimir]

I am not sure if these parameters have changed in R80.10, but it may be worth investigating:

Advanced NAT-T Configuration

These variables are defined for each gateway and control NAT-T for site-to-site VPN:

Item	Description	Default Value
offer_nat_t_initator	Initiator sends NAT-T traffic	true
offer_nat_t_responder_for_known_gw	Responder accepts NAT-T traffic from known gateways	true
force_nat_t	Force NAT-T even if there is no NAT-T device	false

The variables can be viewed or changed in GuiDBedit under:

TABLE > Network Objects > network_objects > <gateway_object> > VPN.

[Tom_Coussement]

On both objects, check point fw and fortigate:

ike_support_nat_t = true

offer_nat_t_initiator = false

offer_nat_t_responder_for_known_gw = true

force_nat_t = false

So offer_nat_t_initiator is not the default value.

while searching for the meaning of this value, I found sk32664 so it seems there has been changed something 

I will have to change the authentication to certificate on the fortigate and change the fortigate object to dynamic.

Will let you know if this works.

Thx for pointing me to this direction.

[Vladimir]

Any updates?

[Tom_Coussement · Accepted solution]

Yes, I was finaly able to test today.

Changing the setting offer_nat_t_initiator from false to true seems to be sufficient.

Seems like this setting has only vallue true as default with fresh R80.10 installations.

When upgrading from previous versions this vallue is default set to false.

Checked on 3 installations where I did an upgrade from R77.30 to R80.10

[Vladimir]

That's how it should work according to sk.

The certificate and the dynamic object seem to relate to a pre-r80.10 versions.

Glad to hear that you've got it to work.

[Sony_James]

We had the same issue with peer end Fortigate firewall, tried changing the setting offer_nat_t_initiator from false to true and it worked.