Hello,
I'm trying to get ZTNA up and running and have the following:
EMS and FortiClients running 7.2.4
FGT600F running 7.0.14, linked to EMS and 'seeing' the configured ZTNA tags
I have successfully set up ZTNA tags and policies on EMS and I can see these on the FortiClients. The clients are showing the tags that I expect.
I have a ZTNA profile configured on the EMS as follows (IPs are made up but principle is the same):
Destination Host: 10.1.1.1:443 (real IP and port of the server)
Proxy Gateway: 111.112.113.114:9443 (external IP and port configured in ZTNA server on 600F)
I have configured the ZTNA server on the 600F as follows:
External IP: 111.112.113.114
External port: 9443
Certificate: <valid wildcard cert>
Server Mapping:
- Type: IPv4
- Service: HTTPS
- Virtual Host: Any
- Match path by: Substring
- Path: /
- Server type: IP
- Server IP: 10.1.1.1
- Server Port: 443
- Server Status: Active
I have a ZTNA rule on the 600F as follows:
Incoming interface: Internet Interface
Source: all
ZTNA tags: <applied using tags that are on the forticlients>
Match tags: any
ZTNA Server: <the server configured above>
Destination: all
Action: Accept
Policy: Enabled
From inside the network (on-fabric), I can merrily browse to 10.1.1.1:443 so I know the server is up and listening.
From out the network (off-fabric) on a laptop that has FortiClient running and connected to EMS, I can successfully browse directly to the proxy gateway at: 111.112.113.114:9443. The firewall prompts for the certificate from EMS on the client side and then allows the connection. This proves the ZTNA tags and ZTNA rule is working. If I apply a tag that the client does not have, the firewall does not allow the connection and give me a ZTNA error. Good.
From out the network (off-fabric) on a laptop that has FortiClient running and connected to EMS, if I browse to 10.1.1.1:443, the client does correctly 'proxy' this to 111.112.113.114:9443 because I can see this arrive on the firewall via a packet capture. But the firewall does not proxy the connection to the real server. No error. Just a timeout.
Any ideas? I'm pretty sure I've configured everything correctly. Could it be a bug?
Many thanks in advance!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hello Matt,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Thanks,
Many thanks @Anthony_E.
UPDATE: seems some existing VIPs were conflicting with the ZTNA config. Removed the VIPs and now it work working. However, it only works via TCP forwarding. It doesn't work with native HTTPS. Any ideas why this might be?
Created on 04-22-2024 07:27 AM Edited on 04-22-2024 07:37 AM
When browsing the ZTNA server for the internal network, on-fabric. Most likely this kind of issue occurred due to the hairpin effect.
You can resolve this issue by applying the incoming interfaces and listening interface (wan) in the ZTNA policy. Try assigning 'any' interface in the ZTNA policy, if you are unaware of the incoming interfaces.
Let us know, if that resolves the case.
Hope that helps,
Kind Regards,
Bijay Prakash Ghising
Hi @mattw,
You will need to collect debugs to see why it is not working. Please refer to the following links:
You can also run packet sniffer on port 9443 to make sure it is reaching the FortiGate:
di sniffer packet any 'port 9443' 4 0 l
Regards,
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1518 | |
1018 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.