Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Markyeye995
New Contributor

Issue with loading application when connected via SSL VPN or S2S VPN

Hi.

 

I'm having this strange issue with a customer.

I'm new to FortiGate so would appreciate any ideas on how to troubleshoot this. 

 

The customer when connected to the main office remotely (SSL VPN) or from another branch office (S2S VPN) cannot login to their Syspro application.

Basically the application just hangs. 

 

When at the office there is no issue as Syspro server resides on the same LAN as the users, so this traffic is not been inspected by the FortiGate.

 

For troubleshooting the SSL VPN rule allows everything and there are no security profiles enabled nor SSL Inspection.

There is no latency or Interface errors. 

 

What I do see all the time is that the Syspro server (10.0.0.4) sends a rst before there is an ack from the client to complete the 3-way TCP Handshake as shown below.

Then there is some communication, connection is terminated and we see a new connection. 

 

The server is listening on the port (30110) and there is no local firewall either. 

 

diagnose sniffer packet lan 'host 192.168.168.23 and host 10.0.0.4'
interfaces=[lan]
filters=[host 192.168.168.23 and host 10.0.0.4]
15.184415 192.168.168.23.54336 -> 10.0.0.4.30110: syn 2758014379
15.184765 10.0.0.4.30110 -> 192.168.168.23.54336: syn 1525188604 ack 2758014380
15.184788 10.0.0.4.30110 -> 192.168.168.23.54336: rst 0
15.201736 192.168.168.23.54336 -> 10.0.0.4.30110: ack 1525188605
15.211346 192.168.168.23.54336 -> 10.0.0.4.30110: psh 2758014380 ack 1525188605
15.211651 10.0.0.4.30110 -> 192.168.168.23.54336: psh 1525188605 ack 2758014440
15.284794 192.168.168.23.54336 -> 10.0.0.4.30110: psh 2758014440 ack 1525188606
15.285156 10.0.0.4.30110 -> 192.168.168.23.54336: psh 1525188606 ack 2758014663
15.344390 192.168.168.23.54336 -> 10.0.0.4.30110: psh 2758014663 ack 1525188817
15.344583 10.0.0.4.30110 -> 192.168.168.23.54336: psh 1525188817 ack 2758014664
15.378383 192.168.168.23.54336 -> 10.0.0.4.30110: fin 2758014664 ack 1525188818
15.378569 10.0.0.4.30110 -> 192.168.168.23.54336: ack 2758014665
15.378586 10.0.0.4.30110 -> 192.168.168.23.54336: fin 1525188818 ack 2758014665
15.394618 192.168.168.23.54336 -> 10.0.0.4.30110: ack 1525188819
15.427545 192.168.168.23.54337 -> 10.0.0.4.30110: syn 731797268
15.427913 10.0.0.4.30110 -> 192.168.168.23.54337: syn 3970939247 ack 731797269
15.427936 10.0.0.4.30110 -> 192.168.168.23.54337: rst 0
15.444257 192.168.168.23.54337 -> 10.0.0.4.30110: ack 3970939248

 

 

3 REPLIES 3
vasilisgogos
New Contributor III

Hi,

Sometimes the issue is fixed by changing the policy from flow to proxy.

Try the bellow :

1- Disable NPU on the SSl VPN policy

2- Change the tcp-mss of Access policy to some value lower than 1500 like 1280

 

Vasilis

Senior Network Security Engineer
Senior Network Security Engineer
Markyeye995

Hi,

None of the solutions made a difference.

Customer is going to escalate to Fortinet.

Personally, I don't believe it is a FortiGate issue

AEK
SuperUser
SuperUser

As per my experience the reset from server is always caused from server side. So far I didn't meet any case where the server reset was caused by FGT.

In other words you should try check the Syspro application logs to see why the server has terminated the session.

AEK
AEK
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors