- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
