SSL VPN users can`t reach web service on WAN2 interface

[zao_gnom]

Hi all.

I recently had a problem with publishing web services to users in my local network which i resolved with the help of comuinity.

https://community.fortinet.com/t5/Support-Forum/Internal-users-can-t-reach-web-service-on-WAN2-inter...

Solution was hair-pin feature

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-Hairpin-NAT-VIP/ta-p/195448

Once again thank you @xshkurti @GauravPandya 

Following up on that topic, I now have several users who are connecting via SSL VPN. When they establish the VPN connection, they can no longer access the web services published on the WAN2 interface.

All traffic from the VPN tunnel needs to go through FortiGate, so split DNS for the VPN portal is not an option, and public DNS records are held by a third-party registrar.

I tried creating another firewall policy with the hairpin feature, but when I select the incoming interface to be the "SSL-VPN tunnel interface (ssl.root)", I can't select the virtual servers because they don't appear in the list at all.

Is the hairpin feature even the solution to this problem, or do I need a different approach?

BR

[dbhavsar]

Hello @zao_gnom ,

- If you are hosting the services behind the FortiGate itself, try creating the policy from ssl.root to your internal interface and see if that helps.

[Debbie_FTNT]

Hey zao,

Virtual Server/VIP objects can't be used in conjunction with SSL-VPN policies. Are the real servers accessed via FQDN or IP?

If FQDN, I would suggest that you allow the hostname to resolve to the internal, real IP as well, so that when users connected via VPN try to connect, DNS lookup returns the internal IP, and the servers in question are accessible via that.

If these servers in question are only accessible via IP, then I'm not entirely sure how that could be resolved - the traffic would have to leave FortiGate towards internet, and then be routed back to FortiGate to hit unrelated policies with the VIP/virtual server, I guess, but that's messy :/.

[zao_gnom]

i already have that policy and it works for services other than https.

It seems like it's not resolving only by hostname

I assume the problem is that the DNS record for that web service (and whole public domain) is on an external DNS server, and when the users connects to the VPN tunnel, they first ask the local DNS server where "mypublicdomain.com" is, and the local server doesn't know because I don`t have forward zone for "mypublicdomain.com" so request is droped?

If my assumption is correct, is there a way to point this kind of request to external DNS with Fortigate or solution would be to create forward zone for "mypublicdomian.com" on my local DNS server (split DNS)