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

SSLVPN web mode - "SSL VPN Proxy Error. Reason: Access Denied."

Hi all,

I've a FG-1800F that I've upgraded to 7.0.16.

SSLVPN tunnel mode works well, but SSLVPN  web mode have a problem when i try to connect using http/https or other protocols.

It shows the message "SSL VPN Proxy Error. Reason: Access Denied".

I state that firewall policies are correctly configured so much so that I can navigate via tunnel without problems.

By debbuging I see the ouptut below:

[5530:root:56b2]deconstruct_session_id:709 decode session id ok, user=[testuser], group=[VPN],authserver=[LDAP],portal=[fullaccess],host[x.x.x.x],realm=[],csrf_token=[BF28A52BF8CD26D67351B134F895BF9],idx=4,auth=16,sid=3e129ec9,login=1732875556,access=1732875556,saml_logout_url=no,pip=no,grp_info=[FP00ys],rmt_grp_info=[pSVTnq]
[5530:root:56b2]dns_query():296 tried IPv4 0 www.google.com
[5530:root:56b2]dns_on_read():178 got result
[5530:root:56b2]sslvpn_policy_match:2641 checking web session
[5530:root:56b2]remote_ip=[x.x.x.x], user=[testuser], iif=34, auth=16, dsthost=[www.google.com], portal=[full-access] realm=[(null)], dst=216.58.209.36, dport=80, service=[http]
[5530:root:56b2]sslvpn_policy_match:2666 policy check cache found [deny]


What could be the problem?

Thanks.

1 Solution
sjoshi
Staff
Staff

Hi,

 

Please share below cmd while connecting the ssl vpn

PuTTY SSH1:
------------

get vpn ssl monitor
diagnose vpn ssl list
diagnose firewall auth list
dia vpn ssl statistics
exec vpn sslvpn list
get system status
diag vpn ssl stat


PuTTY SSH2:
------------

diag sys flash list
diag debug reset
diagnose debug console timestamp en
diagnose vpn ssl debug-filter src-addr4 x.x.x.x - Here x.x.x.x is the public IP of the user connecting.
diag debug appl sslvpn -1
diag debug appl fn -1
diag debug enable

wait till the VPN disconnect, disable the logs by executing

diag debug disable
diag debug reset

Let us know if this helps.
Salon Raj Joshi

View solution in original post

9 REPLIES 9
ametkola
Staff
Staff

Hello @zero_net ,

 

We usually see this error when there is no policy to the destination.
You can check the Policy Lookup feature at the top of the firewall policies page to check if any policies will correctly allow the traffic.

Go through also the article below which seems to match with your case:
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-SSL-VPN-Proxy-Error-Reason-Access-De...

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-fix-randomly-failing-SSL-VPN-with/t...

 

Regards,

 

zero_net

Hi @ametkola,

policy to destination (to internet) is the same matched by SSLVPN tunnel traffic (split-tunneling disabled) that surfs without problems. If I check the policy lookup from ssl.root to www.google.com, as suggested, traffic matches that policy correctly...

So, policy works well by tunnel but not by web mode.

 

Thx.

 

 

dingjerry_FTNT

Hi @zero_net ,

 

Could you please share the firewall policy allowing the web mode traffic?

Regards,

Jerry
zero_net

Hi @dingjerry_FTNT ,

this is the policy internet fort SSLVPN users (matched by tunnel but not by webmode)policy.png.

 

Thx.

dingjerry_FTNT

Please use "all" for the source IP.  Otherwise, this policy will match the "VPN" object (I guess it is for your SSL VPN tunnel mode client IP range) only.

Regards,

Jerry
sjoshi
Staff
Staff

Hi,

 

Please share below cmd while connecting the ssl vpn

PuTTY SSH1:
------------

get vpn ssl monitor
diagnose vpn ssl list
diagnose firewall auth list
dia vpn ssl statistics
exec vpn sslvpn list
get system status
diag vpn ssl stat


PuTTY SSH2:
------------

diag sys flash list
diag debug reset
diagnose debug console timestamp en
diagnose vpn ssl debug-filter src-addr4 x.x.x.x - Here x.x.x.x is the public IP of the user connecting.
diag debug appl sslvpn -1
diag debug appl fn -1
diag debug enable

wait till the VPN disconnect, disable the logs by executing

diag debug disable
diag debug reset

Let us know if this helps.
Salon Raj Joshi
zero_net

Thanks for your support @sjoshi.

While debugging the traffic I found the policy that was blocking Internet traffic:

policy_match_check:223 selected policy id: 512, policy position: 2, policy action: deny.

 

The strange thing, however, is that using the policy lookup from the GUI the right policy was matched to the internet (not policy id 512).
In this way it was impossible to identify the problem without debugging.





 

 

 

 

dingjerry_FTNT

Hi @zero_net ,

 

I guess you specified the destination IP only for policy lookup?

Regards,

Jerry
zero_net

obviously yes.

 

Thx.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors