locked
Reverse Proxy on TMG problem with meet - error 500 from IIS RRS feed

  • Question

  • OK this is what the configuration looks like:

     

    The site is working great and federates with my former OCS environment with no problem. After weeks of problem after problem and slowly resolving each one, I only have one more issue. This is with Reverse Proxy on TMG. Everything works locally and I get the expected webpage when I go to http://meet.<mydomain>.com. I am trying to set up reverse proxy for external users. I have the Web Listener and the Web Publisher configured according to typical settings, and I get (another) weird error. This is happening to meet... but not dialin! 

     

    Error: Unexpected response was received from server. HTTP response: 500 Internal Server Error

    Whatever this message means, I would have expected it to happen to pool01, and dialin too. Keep in mind that meet and dialin works internally so I am not sure why I would get this error from the TMG server in the DMZ.  

    Here are the configurations of TMG:

    [NETWORKING]

    Internal Addresses are: 10.0.0.0-10.255.255.255, 172.16.0.0-172.16.255.255, and 192.168.0.0-192.168.255.255

    Routes Are:

    Dest:10.0.0.0 Mask:255.0.0.0 GW:192.168.XX.XX

    Dest:172.16.0.0 Mask:255.255.0.0 GW:192.168.XX.XX

    Dest:192.168.0.0 Mask:255.255.0.0 GW:192.168.XX.XX 

     

    [WEB LISTENER]

    Networks: Set to External

    Connections: Enable http-80, Enable SSL-443, Do not redirect

    Authentication: None

     

    [WEB PUBLISHER]

    Bridging: Redirect HHTP-8080, Redirect SSL 4443

    Web Farm: "Forward the original host header" is checked.

     

    Nothing else... So I have a single Web Listener, a single Web Publishing rule, a single server farm with my two FE pool servers in it. all other settings default.

     

    Why am I getting an error on http://meet.<mydomain>.com? It is seamingly coming from IIS but again it works internally and obviously TMG can reach the IIS service.


    DRaGoNFLy
    Friday, September 23, 2011 5:11 PM

Answers

  • Yes. For me, communication with the front end was not a problem on 8080 or 4443. It was getting communication from external to the RP server on 443 (and 80) that was the initial problem.

    I figured out my problem though and this issue can be closed. I will elaborate if needed but for now the details are that I removed TMG and started by confirming that my NAT and firewall rules were set correctly. Then I checked the same from RP to the Lync FE pool. Once I could communicate to RP properly (checking the ports with telnet). Then I reinstalled TMG to find the exact same problem.  This told me that TMG was the problem and was blocking traffic. A little research in the TMG logs and I found the problem...

    Under this configuration my internal addresses were set up as:

    10.0.0.0 - 10.255.255.255
    172.16.0.0 - 172.16.255.255
    192.168.0.0 - 192.168.25.53
    192.168.25.55 - 192.168.255.255

    This put my external NIC in the external network. I had the Web Listener set to ANY IP from the external network. Which didn't work. Then I changed the Internal network IPs to:

    10.0.0.0 - 10.255.255.255
    172.16.0.0 - 172.16.255.255
    192.168.0.0 - 192.168.255.255

    This put both NICs inside the internal network. Then I set the Web Listener to listen to the internal network but specified the external NIC address so that the listener is only listening to the external NIC. That worked and traffic flowed to the FE servers properly! I was under the impression the first configuration was correct. I would love to know why it didn't work.

    As for the odd error on meet that I get while testing the . I still don't know why it is throwing a 500 error. The site appears to be coming up fine externally. I need to do more testing. Maybe the typical "Meeting URL is not valid." error that we get when testing the simple urls shows up to TMG as a error 500... I don't know. But it is working so far.


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Tuesday, October 4, 2011 1:02 PM

All replies

  • On more thing...

    I noticed that the attempt to communicate with the internal Fron-End Pool is coming from the external IP address on the TMG server. Shouldn't it be coming from the internal NIC? I can't get that to happen unless I give the internal NIC the gateway address, which I was told we should not do. 

    That first hop was the external address not the internal NIC address. >>Exactly<< what do I do to allow the internal NIC the ability to contact the FE Pool?

     


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Friday, September 23, 2011 5:20 PM
  • Please try the following solution:

    1,Please make sure that the TMG internal interface is on top in the connections(Network connections--Advanced settings--Adapters and Bindings).

    2,Read the following article and specify the the interface number for this routes.

    http://technet.microsoft.com/en-us/library/dd440984.aspx


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, September 26, 2011 8:47 AM
  • That worked great to direct traffic through the correct interface. Thank you. 

    Now I only need to figure out why "https://meet.<mydomain>.com" isn't working externally but everything else is. It appears that it is getting to IIS but it is interpreting the IIS replay as an error. However "meet" works on the LAN. (See the error 500 listed above).

    Can anyone help with that?

    I don't see an indication that there is something corrupt with the site (especially if it is working internally). But if it is, how to I reset/reinstall it?

     

    Why does https://dialin.<mydomain>.com reply properly, but not meet?

     


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Monday, September 26, 2011 3:16 PM
  • I have this isue also-any one able to help?

     

    Dave

    Wednesday, September 28, 2011 3:14 AM
  • Has anyone successfully set up reverse proxy for meet using TMG? If not, what are you using? I'll just change my configuration to match yours.


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Wednesday, September 28, 2011 12:42 PM
  • I should mention that I am seeing connection attempts in TMG from the external client. I just cannot get through to the IIS servers.

    If that helps...

     


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Wednesday, September 28, 2011 7:01 PM
  • I have this isue also-any one able to help?

     

    Dave


    Mee too, I was wondering if anyone solved this issue yet.
    With kind regards / Met vriendelijke groet, Jetze Mellema | http://jetzemellema.blogspot.com/
    Friday, September 30, 2011 7:33 AM
  • Can you telnet from the Reverse Proxy to the Lync FE on port 4443. I had the same issue. After recreating the binding on IIS on the front end i could open the website on port 4443.

     


    Sebastiaan Poels www.unifiedcollaboration.nl
    Tuesday, October 4, 2011 12:31 PM
  • Yes. For me, communication with the front end was not a problem on 8080 or 4443. It was getting communication from external to the RP server on 443 (and 80) that was the initial problem.

    I figured out my problem though and this issue can be closed. I will elaborate if needed but for now the details are that I removed TMG and started by confirming that my NAT and firewall rules were set correctly. Then I checked the same from RP to the Lync FE pool. Once I could communicate to RP properly (checking the ports with telnet). Then I reinstalled TMG to find the exact same problem.  This told me that TMG was the problem and was blocking traffic. A little research in the TMG logs and I found the problem...

    Under this configuration my internal addresses were set up as:

    10.0.0.0 - 10.255.255.255
    172.16.0.0 - 172.16.255.255
    192.168.0.0 - 192.168.25.53
    192.168.25.55 - 192.168.255.255

    This put my external NIC in the external network. I had the Web Listener set to ANY IP from the external network. Which didn't work. Then I changed the Internal network IPs to:

    10.0.0.0 - 10.255.255.255
    172.16.0.0 - 172.16.255.255
    192.168.0.0 - 192.168.255.255

    This put both NICs inside the internal network. Then I set the Web Listener to listen to the internal network but specified the external NIC address so that the listener is only listening to the external NIC. That worked and traffic flowed to the FE servers properly! I was under the impression the first configuration was correct. I would love to know why it didn't work.

    As for the odd error on meet that I get while testing the . I still don't know why it is throwing a 500 error. The site appears to be coming up fine externally. I need to do more testing. Maybe the typical "Meeting URL is not valid." error that we get when testing the simple urls shows up to TMG as a error 500... I don't know. But it is working so far.


    Ramon Rodgers, MCP, APlus Network Support Specialist
    Tuesday, October 4, 2011 1:02 PM
  • I see this error also on a ISA 2006 Reverse proxy deployment. I still have to investigate why this error is given during the test rule action. At this deployment the meeting URL works fine...

     

    The meeting url is not valid error should not be the cause of the test rule to fail. I have multiple deployments running and only this deployment has an error with the test rule action...

    It dazzles me...to be contineud at the end of the month.


    Sebastiaan Poels www.unifiedcollaboration.nl
    Wednesday, October 12, 2011 5:34 PM
  • Hi did anyone get a resolution to the 500 internal error for the meet simple URL?
    Monday, January 23, 2012 8:14 PM
  • It seems to be only cosmetic because everything appears to work fine. It's just the testing of the rule that fails.
    With kind regards / Met vriendelijke groet, Jetze Mellema | http://jetzemellema.blogspot.com/
    Monday, January 23, 2012 8:42 PM