1

tl;dr I'm having trouble getting TMG to properly reverse proxy an HTTPS connection on the outside, to an HTTP connection on the inside.

We have a LAN (10.0.7.0/24) that hosts a Windows Server 2008 box, with Spiceworks installed. Spiceworks uses Apache, and is configured to serve both HTTP and HTTPS. So long as you browse it from the LAN, it works, no problems.

We also have a DMZ (172.32.16.0/24) that hosts a Forefront TMG server, which has access to both the LAN and the Internet. So what we've tried setting up is a reverse proxy rule, that would let users access the Spiceworks instance from the internet.

For HTTP, it works perfectly - traffic goes through TMG, and is relayed to the Apache server, groovy. For HTTPS, not so much. TMG establishes the connection using the cert on it's side, but is unable to connect to the Apache server over HTTPS, and dies with a timeout error.

I don't think it's a network issue, as HTTP works fine. It's not an HTTPS issue with Spiceworks, since browsing it on the LAN works fine. I suspect that TMG is having trouble validating the cert we're using on the Apache server, which is why I get an HTTP 500 error "The token supplied to the function is invalid".

The cert that TMG is using is the same cert that's on the Spiceworks server (both a GoDaddy wildcard cert) - could that have something to do with it? We can't replace the cert as it's used in a number of places, so if there's a workaround, or a TMG config setting I can change, that would be perfect.

My other option was to get TMG to proxy https://subdomain.domain.tld:443 on the outside to http://subdomain.domain.tld:80 on the inside, and circumvent the SSL issue entirely, but no dice there, either - TMG stubbornly refuses to rewrite the URL that way.

1
  • can cyou update the post to include the FQDN of the spiceworks server and tmg server. Also the output from when you run "Test Rule" on the TMG publishing rule
    – Phil
    Oct 15, 2014 at 15:41

0

You must log in to answer this question.