I experienced the strangest problem ever with one of our FGT.
It’s a FGT400E running firmware 6.4.15.
There a lot of users connecting via forticlient. I never stumbled upon a problem like this.
There are clients, connecting from Singapore via forticlient. No Problem at all. Doesn’t matter if they work from home or any other free network. Whenever the try the connect from Malaysia, the connection will be refused from the firewall. Logs state:
‘SSL user failed to login’
Same device, same credentials. Only difference ist the location. One user tried multiple locations. Singapore is fine - Malaysia impossible.
No geo ip blocking equiped whatsoever (what’s really bothering me anyway).
We already changed user credentials, ssl groups,… you name ist.
Any thoughts on this, please 
It drives me nuts!
If there’s no difference on the FortiGate and no difference on the endpoint, then logically the breaking point must be somewhere on the path.
Any chance Malaysia does any sort of content filtering that could screw with traffic?
Is your fortigate rejecting the connection attempts? Are you using IPS on the incoming interface’s policy?
Or are your remote users simply unable to reach you?
Ive had problems with users not able to connect. Have them get you their IP (whatismyip.com or something similar) and use
diagnose debug enable
diagnose debug flow filter addr 40.25.63.122
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
Use the ip they give you. If you see activity output in the CLi then yes, they’re hitting your fortigate and you can troubleshoot from there. If there is no debug output in the CLI, they arent even able to reach you.
Once you have what you need, be sure to
diagnose debug flow trace stop
diagnose debug disable
If the output mentions a policy number, you can get more info by using
show firewall policy <number>
As already mentioned by u/pabechan:
If there is no config in the Fortigate that might block anything from Malaysia or any other difference between the endpoints, etc. - then the issue is likely in between (ISPs).
What you can additionally do (if you haven’t yet) is to check with tcpdcump/sniffer/packet flter whether or not you see traffic arriving from the public IP of the end user that tries to open a SSL VPN connection…and then compare it with a connection that works (if you get packets at all).
If you don’t get packets at all from the end user, well…then its pretty clear. If you receive some, you might need to compare it with a working connection in order to see if there are packets or responses missing.
In any case - with the information provided, this sounds like an issue “in between”.
Try connecting from different ISPs, TM and TIME. Do they behave the same? Traceroute or using pingplotter, like others mentioned, “in between” issue from ISP side as there are many routing involved. Different ISPs different routes.
Get the following:
di de reset
di de di
di vpn ssl debug-filter clear
diagnose vpn ssl debug-filter src-addr4
diagnose debug application sslvpn -1
diagnose debug application fnbamd 0
diagnose debug console timestamp enable
diagnose debug application samld -1
diagnose debug enable
Also, can you share:
Show vpn ssl settings
Diag ip add list
Feel free to open a tac ticket and share the ticket id, I’ll take a look at the logs
I too have experienced similar issue. I have OpenVPN server in India and one of the employees wanted to connect to remote server. I even changed the connection protocol from UDP to TCP. Still failed to connect. So only reason is Malaysia doing some kind of geoIP blocking.
I can see the requests in the firewall log. So the requests aren’t blocked in Malaysia. It seems to be the fortigate (Europe) who is coursing trouble. I checked the ips from the logs. There are different ips from Malaysia which are denied. Same user, other ip (Singapore) works just fine.
The Fortianalyser says: ssl user failed to logged in. Sslvpn_ligin_permission_denied.
I tested SSL inspection in our company, it worked just fine (deploying the certificate on every PC etc). The only thing that was non functional was to connect to other Fortigates via SSLVPN. Same behavior, I saw packets on the other side but I could not authenticate. Forticlient would throw an error. My guess is that Malaysia does some kind of „nation wide ssl inspection“, similar to the great firewall in china🤷♂️ I don’t know, just my guess… Did you take a look at the Forticlient log files?
Thanks a lot for your ideas! The user is definitely reaching the firewall. I can see the attempts. We also successfully tried ping, telnet, web access, tracert… No Problem.
I will soon check if ips is enabled for the policy. Good thinking.
I can see the connection attempts on the firewall. Tracert, telnet, ping were successful.
Could it still be the ISP?
For me it looks like the Fortigate is rejecting the attempts.
i only mention IPS because if the source IP is part of some threat list in fortiguard, IPS might be causing it to fail. Thats the only reason i bring it up.
Ok. But in that case i would expect an utm notification in the logs rather than an “permission denied”. But i had similar thoughts. Blocklists and stuff. But the user tried different locations and i saw a few different IPs from different networks.
Is this just one user? Maybe try and create another user account for them to try?
There are more users having the same issue. We also created a new user. Working just fine - except you are in Malaysia 
