Fortigate SSLVPN client/server will not pass traffic unless "diag firewall iprope flush" is issued.

[aguerriero]

This is across multiple firewall client types running 7.0.12 and 7.2.5.

The VPN head end is running 7.2.5.

When configuring the fortigate as an SSL VPN Client connecting to another fortigate acting as an SSL VPN concentrator the tunnel will come up but traffic will not pass until the command "diag firewall iprope flush" is issued from CLI. Traffic will immediately start passing as soon as the command is issued.

If the device is rebooted the device will again not be able to pass traffic until the command is run.

I guess this command could be scheduled hourly but I would rather identify the issue so the command does not need to be entered at all.

[aguerriero]

I created an automation stitch that will issue the cli command "diag firewall iprope flush" for log event  interface status change log id 20099 and interface status of UP.

For it to it to work consistently I had to issue the same action twice with ~15 and ~7.5 seconds of delay between trigger and actions.

[srajeswaran]

Great finding the workaround. Can you collect "diagnose firewall iprope list 00100004 " during the issue state /before flushing the iprope table and then collect same command after the fix?

We can check if there is any changes to the policies and then investigate further.

[aguerriero]

I eran the list and then the flush. From the image below it looks like I don't get anything from that list command after flushing. 

[aguerriero]

Something peculiar. I enabled local-in policy and it appears that my ssl interface does not ever get policies created for it.

 
If I enable HA mode and set it to a-p I now have the option to set a management IP address.  If I manually set the management IP, everything works as expected and I never have to flush iprope. Even though the IP address is being set by the IP pool in the hubs portal configuration, because there isn't a manual IP address assignment on the tunnel interface local in policies are never created.

Here is a screenshot after enabling HA A-P and manually setting a management ip.

 

 

You could say that running a standalone in ha a-p mode and manually setting an IP is a workaround. But I have over 900 standalone spoke firewalls.

[srajeswaran]

Interesting finding. This needs remote session to understand better. I would suggest to open a support ticket to verify/validate the configuration according to your design/connectivity .

[aguerriero]

I will submit a TAC case based on your recommendation.

Thank you.

[srajeswaran]

With no entries in iprope list traffic is not expected to work, are you sure the traffic was working when you collected the output (after executing the flush command)?

[aguerriero]

Traffic to the fortigate itself doesn't require a standard policy. From what I see, the fortigate relies on those check boxes in the admin section to create local-in policies. Those policies never get created because the fortigate doesn't have an IP set, even though it has received an address from the portal through ip pool configuration. It exists as a directly connect route associated with the tunnel interface.

The proof is in the repeatability. After a clean reboot it does not work until I issue an iprope flush. Assigning a management IP address manually through CLI works, but you can only assign a management ip address if the system is running in an ha mode other than standalone.

 

 

[pgautam]

Hi,

Please share the below details at the time of the traffic issue:-

get router info routing-table details <src IP>
get router info routing-table details <dst IP>
++ Do you have any policy route or SDWAN configured at the client site?

dia sniffer packet any "host <server_IP>" 4 0 a 

Regards

Priyanka