Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 2740 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ZTNA agentless resources on port 443 not working (no healthy upstream)

Philipp N.

Hello,

I recently set up ZTNA with our XGS (v20) as gateway to test ZTNA as an alternative to VPN.

Setting this stuff up worked like a charm until I reached the point of accessing resources...

I tried to add agentless resources with internal FQDN server-A.mydomain.local with HTTPS/443 and then access them with a authenticated user.
But the browser returns error "no healthy upstream".

I can confirm, that DNS resolution is working properly because after adding a different FQDN resource with a port different than 443 (e.g. Webadmin 4444 or any other internal web app that is listening on a different port than 443) was successful.

Is there any way to debug the behaviour on the firewall? I mean it is nice they added the ZTNA Gateway feature but without logs it is almost impossible to dig deeper in a specific direction.

My humble assumption is:

The ZTNA releated traffic somehow gets affected by the web proxy.

Because:

Running curl commands for two different web services on the console return different results.

curl https://server-A.mydomain.local:443

-> Reset by peer (the peer in that case is our Upstream Proxy we have to use, could confirm it by using http/80 instead)

curl https://server-B.mydomain.local:9710

-> correct answer from actual webserver



This thread was automatically locked due to age.
Parents
  • 0

    Ztna client less always provides https 443 to the client. But can do an every other port on the backend system. 
    Your error means, the firewall cannot reach the resource (on the given port). 

    Your client should open the resources on 443 and the firewall will translate it transparent to 9710. 
    if your resource needs to be reached on 9710 (by the client itself) then you should look into an client approach. 

    clientless also requires to have a public dns pointing to central. So not using a local domain is key here. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hi,

    I guess I was not clear enough on what the issue is.

    The problem is not with webservices running on ports other than 443 internally. The resource with port 9710 for example works fine agentless.

    The problem is with webservices running on port 443 internally. The CNAME record got created correctly so I can access service.public-domain.de and have to authenticate against the IDP. After authentication I receive "no healthy upstream" despite the fact that the firewall is able to resolve the internal FQDN.

    The ZTNA related internal traffic on port 443 gets routed through the upstream proxy on the firewall if configured and never reaches the actual internal target.

    It is either a bug/flaw or it needs some configuration on my firewall which I am missing.

  • 0 in reply to Philipp N.

    So basically you are saying: If you have a Parent Proxy on SFOS, SFOS will use the Parent Proxy for the Clientless Traffic (SFOS to app)? 
    Did you verify this via tcpdump or how do you know, SFOS is doing this? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Yes I am just assuming this.
    I did not use tcpdump to verify this, because I do not really know how to catch that specific traffic with tcpdump.
    What I tried was to access the resources on the XGS command line via curl. (see post #1)
    Curling the web resource on port different than 443 gives a valid result. Curling the web resource with port 443 gives me an answer from the parent proxy. I know that I am disrigarding the principle of a TCP connection making my assumption based on the curl behaviour but that is the only thing that makes some sense to me.

    Could you assist me on how to catch that specific ztna related traffic with tcpdump on the firewall?

    Btw.: In the meantime I set up a ZTNA gateway with a VMWare VM. Using the VM gateway instead of the firewall the connection to a 443 resource works fine.

Reply
  • 0 in reply to LuCar Toni

    Yes I am just assuming this.
    I did not use tcpdump to verify this, because I do not really know how to catch that specific traffic with tcpdump.
    What I tried was to access the resources on the XGS command line via curl. (see post #1)
    Curling the web resource on port different than 443 gives a valid result. Curling the web resource with port 443 gives me an answer from the parent proxy. I know that I am disrigarding the principle of a TCP connection making my assumption based on the curl behaviour but that is the only thing that makes some sense to me.

    Could you assist me on how to catch that specific ztna related traffic with tcpdump on the firewall?

    Btw.: In the meantime I set up a ZTNA gateway with a VMWare VM. Using the VM gateway instead of the firewall the connection to a 443 resource works fine.

Children
No Data
Unfiltered HTML