FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
mkhabbazi
Staff
Staff
Article Id 270519
Description

This article describes a couple of issues related to SSL VPN Full Tunnel configuration that may arise after upgrading the firmware to versions 7.2.5 or 7.4.0.

Issue 1: Unable to create firewall policy.

If there are any SSL VPN portals with the option ‘Split tunneling’ enabled, and they are applied to any ‘Authentication/Portal Mapping’ under SSL VPN Settings, an error message will be presented while creating a new SSL VPN firewall policy with destination address set to ‘all’ even though the group applied to this new policy is mapped to an SSL VPN portal with the option ‘Split tunneling’ disabled.

 

Destination address of split tunneling policy is invalid.
SSL-VPN portal "<name>" has split tunnel enabled, which does not allow policy IPv4 destination address to be "all".
Node_check_object fail! for name all.


1.png

 

The expected behavior is to be able to configure an SSL VPN firewall policy with destination address ‘all’ when the user group is mapped to an SSL VPN portal in which the ‘Split tunneling’ option is disabled.

 

Issue 2: Destination address object removed upon reboot.

 

Upon a firewall reboot, while running FortiOS 7.2.5 or 7.4.0, any existing SSL VPN firewall policy with the destination address set to ‘all’ will have the address object removed, which may cause traffic to fail.

 

2.png

Scope FortiGate v7.2.5 and v7.4.0.
Solution

This is a known issue has been addressed in FortiOS versions 7.2.8 and 7.4.2 (IDs 879329 and 930275).

Workaround for the issue affecting the creation of firewall policies.

 

Method 1.

  • While creating the firewall policy, apply any firewall address object other than ‘all’ in the destination address field, and save it.
  • Edit the newly created firewall policy, apply the firewall address object ‘all’ to the destination address field, and save it.


Method 2.

  • Create a firewall policy from CLI; however, set the user group prior to setting the destination address.
  • That will allow the firewall policy to be saved with ‘dstaddr’ field set to ‘all’.

 

Workaround for the issue affecting firewall policies upon firewall reboot.

  • Edit affected firewall policies, set the destination address field to 'all', and save them.

Workarounds to avoid running into the reboot issue (Issue 2):

  • Workaround 1: Instead of 'all', the destination can be set as '0.0.0.0/1' + '128.0.0.0/1'. (Split 'all' into two networks).
  • Workaround 2: Use the full tunnel in a separate realm. When used in a separate Realm, it should be possible to configure the destination as 'all' or to create a new address object for '0.0.0.0/0' which can then be used in the policy.

These workarounds can ensure that the issue is not seen again, after a reboot (bug 879329).