friends can you help me with this query:
I have been informed of a user accessing the VPN and unable to access internal company resources.
I have reviewed the logs and no blocking is observed by the firewall (policy violation), I see that there is traffic but the actions shown in the logs are:
* close
*timeout
*client-rst
What would be the reasons why the firewall has this action? Is the fortigate responsible or the destination server?
I would believe that the destination server, but how could I validate it?
The internal ips are within the access policy and within the ssl portal. Also, all ports are “all” so I wouldn’t know what the problem would be.
Doesn’t seem to be the firewall. Are there any logs on the client or server?
Is this a new user? Or was it working until recently? If new, what version of Forticlient? We are on 7.0 train but FGT SSL VPN has issues with IPv6 DNS resolution. If your users ISP is IPv6 it’s possibly they can resolve external but not internal sites if you’re not using IPv6. Have them try lookup of public and internal. If they can’t resolve internal and you see IPv6 response, you’ll need to disable v6 at the client. That was the only resolution given to us
Have you enabled SSL inspection? The client may reset the connection itself, being unhappy with the certificate provided by the service.
but how could I validate it?
Test the connection. If you don’t get a response you know it’s the server.
Running the capture from the server side will verify the client packet is arriving.
When you see timeout or reset, it’s either the server you are trying to reach or a routing problem on the remote. If the server is over a different network not within the firewall, don’t forget to advertise the vpn route to the other side. Note this is just for the timeout and not the client reset. Having said that though it’s hard to tell based on just the info you provided.
What version of fortios are you on? 7.2.5 has a bug with SSL VPN and PPOE. Article for reference
Fix is to delete and readd the interface details.
Close
Regular closure of a TCP session (FIN-ACK exchange). Naturally this can only happen if the traffic was first allowed to begin with.
timeout
Session timed out. This can happen if the session is quiet for an extended time (no packets in either direction). Default timeout for TCP sessions is 1 hour.
Client-RST
Client ended the session with a RST instead of a “proper” FIN-ACK exchange. This could be an issue, but “client sent a RST” gives absolutely no indication as to where the issue may be. We should also point out that in some protocols, ending a session with a RST is “normal”. (e.g. Windows AD LDAP likes to end communication with a RST sent right after a client sends an unbindRequest)
did you open a case with the tac?
you mean politics? in the policy, only ssl no inspection is enabled
Do you mean doing a telnet or ping to the destination IP?
you did not understand, do you mean telnet or ping the destination ip?
previously it was accessed normally, this problem is recently occurring.
I did. We actually determined it was IPv6 and disabled it for affected users as a workaround. Then opened a support ticket and were told official remediation was to disable IPv6, and it wasn’t a bug ID to be fixed in future versions
Or just try to access server resources normally.
Put Wireshark on the server, filter for the client’s VPN address, see if any traffic arrives. If you see traffic but the user can’t connect, answer is probably with the server.
If you suspect the firewall, debug the VPN daemon, run a flow trace, and pcap the traffic on the firewall.
Basic admin stuff.
Lastly, your log says it’s a client reset packet. That means the firewall sees the traffic, allowed it through, but then the client at some point forced the season to end without completing. Since the traffic made it through the firewall, I’d start looking at the server instead of wasting time trying to double-prove it’s not the firewall
You can try doing a lot of stuff, like try pinging the server IP from the firewall, if it works you will at least know that there is a route from the firewall to the server and it’s reachable, then like the other comment said install Wireshark on the server itself and check Wireshark logs, if packets are even arriving or not and are they leaving, check if you can access the server internally from an internal subnet that normally works, etc etc.
On VPN, ask user to share his/her screen (using teams or whatever) take control of it and try pinging the server, see if firewall allows, if it allows verify on Wireshark on the server side, as simple as that.
It could be a ping or it could be whatever type of access the user is supposed to have to the server, like an https access or whatever which you should know.
And yeah installing Wireshark on the server and checking Wireshark logs is absolutely crucial to solving these sort of problems.
Interestingly enough. We have this same issue with Aruba based VPN. ISPs seem to be enforcing IPV6 in a greater capacity lately.
We also have not developed any solution. Maybe implement ipv6 in the internal environment? Lol
