Note: Forums will be making significant UX changes to address key usability improvements surrounding search, discoverability and navigation. To learn more about these changes please visit the announcement which can be found HERE.
Need help with ForeFront TMG as Hyper-V guest connected to DMZ VLAN

Answered Need help with ForeFront TMG as Hyper-V guest connected to DMZ VLAN

  • Thursday, January 17, 2013 11:40 PM
     
     

    I have a ForeFront TMG server configured as Hyper-V guest connected to a DMZ VLAN on switch.

    The host has 2 nics, one connected to the internal network and another to the external network (DMZ) on the switch.  The TMG guest has access to both internal and external nics.  The external NIC shows as 'internet access' on the network settings.

    I have the firewall NATed correctly, and the ports opened, but when I run a port checker I can't find open port 443 from outside on the IP.

    I also cannot load the mobile Lync app and have it connect.

    All the certs and DNS settings have been validated by a 3rd party.

    Is there something the host computer is doing that may affect this configuration?  The host firewalls are off.  

    TMG server 443 ports listening screen cap (below)

All Replies

  • Thursday, January 24, 2013 9:39 AM
    Moderator
     
     Answered

    Hi,

    Thank you for the post.

    As far as I understand, this issue may occur if IIS was running and was bound to port 443 for https. So please did netstat –ano for TCP port 443 to check if the IIS or other service was running and bound. If that is true, please disable the IIS services and restarted TMG firewall  services.

    Regards,


    Nick Gu - MSFT

  • Wednesday, January 30, 2013 2:53 AM
     
     

    sorry for the delay.  i didn't get an answer for a while and stopped checking daily.

    IIS is not running.  screenshot shows the ports and services.any other ideas?

  • Wednesday, January 30, 2013 4:12 AM
    Moderator
     
     

    Hi,

    Thank you for the update.

    According to the screenshot, firewall service is correctly bound to port 443. I’d like to confirm if the ip address:10.32.24.11 is the external ip. Is there any other device in front of TMG that block the traffic.

    Regards,


    Nick Gu - MSFT

  • Thursday, January 31, 2013 12:13 AM
     
      Has Code

    24.11 is not the external IP but 66.104.83.75 is.

    24.11 the ip to the perimeter network (DMZ)  The external IP is NAT'd to that address via the firewall.  

    nat (DMZ) 1 0.0.0.0 0.0.0.0
    nat (Guest) 1 0.0.0.0 0.0.0.0
    static (inside,DMZ) 10.32.8.0 10.32.8.0 netmask 255.255.255.0 
    static (DMZ,outside) 66.104.83.72 10.32.24.6 netmask 255.255.255.255 
    static (DMZ,outside) 66.104.83.73 10.32.24.7 netmask 255.255.255.255 
    static (DMZ,outside) 66.104.83.74 10.32.24.8 netmask 255.255.255.255 
    static (DMZ,outside) 66.104.83.75 10.32.24.11 netmask 255.255.255.255 

  • Tuesday, February 05, 2013 1:53 AM
     
     

    I've again validated that the firewall is configured correctly.   Even from other machines in the DMZ I cannot telnet to port 443 on this reverse proxy machine, or even ping it, yet i can ping out.   And that is with all the TMG services disabled and the server restarted.  I added a port listener to test 443 via telnet from another dmz machine (with tmg services off), same result.    Then I saw that there is a TMG packet filter bound to the NIC.  It is unselectable and unremovable.  I tried deleting the NIC and recreating it twice, once as a regular nic and once as a legacy nic.  It is still there.

    I need to remove this to validate 443 connectivity outside of TMG.

    How do I remove this!?   thx!

  • Tuesday, February 05, 2013 8:20 PM
     
     

    You can't - that "is the TMG Firewall" (so to speak). You'd have to deinstall TMG.

    Is this your setup?
    Internal (10.32.8.x) <--> (10.32.8.11) TMG (10.32.24.11) <--> external FW <--> BOBI

    Couple things to check:
    - is the web publishing rule restricted to source networks/IP's?
    - is the web publishing rule set to "Requests appear to come from TMG" and if not, is the default GW of the internal resource 10.32.8.11?
    - did you test the web publishing rule (test button in properties)?

    Thx&Rgds
    Marcus.

  • Tuesday, February 05, 2013 10:13 PM
     
     

    Due to time restraints, i had to hire someone to do the TMG and certificate setup for Lync.   Lync remote via windows client works great, it's only the mobile clients that can't connect and the 443 port showing as closed on an external port checker.

    And yes, that setup is correct and how do i check those 3 things exactly?

  • Wednesday, February 06, 2013 10:08 PM
     
     

    If you do port scans on TMG it's going to interpret that as an intrusion attempt and close the connection (check the alerts section in TMG).

    If your Windows clients work through the TMG, but the mobile clients don't, then I would think the web publishing rule is at least working partially. I'd suggest to monitor TMG traffic for a mobile client to see what's going on and if something is being blocked:
    1. determine IP address of a mobile device
    2. go to TMG console -> "Logs&Reports"
    3. Edit Filter -> add "Client IP" and the IP address of the mobile device
    4. Start Query and attempt a connection with the mobile device

    The three things I mentioned can be checked in TMG Console -> "Firewall Policy" -> right click on your publishing rule, Properties -> "General" Tab, "From" tab and "To" tab.

    Thx&Rgds,
    Marcus.

  • Thursday, February 07, 2013 2:58 AM
     
     

    Marcus, thx for the details.

    actually windows remote Lync was working with our edge server even before the reverse proxy was setup.   also when i try to setup that filter, it shows nothing.   there is an existing condition there that i can't remove (for my username) that i had setup a while ago when trying to do the same thing. but 'remove' is greyed out, and if i try to replace with with the IP one, the only option is to add.  but even with that it should work because that's the username i'm using, but you'd know better than I.

    the 3 other things are: (in CAPS for clarity, sorry)

    - is the web publishing rule restricted to source networks/IP's?  NO (see screencap)
    - is the web publishing rule set to "Requests appear to come from TMG" YES and if not, is the default GW of the internal resource 10.32.8.11?
    - did you test the web publishing rule (test button in properties)?  NO TEST BUTTON




    • Edited by paulman Thursday, February 07, 2013 3:06 AM
    •  
  • Thursday, February 07, 2013 2:59 AM
     
     

  • Thursday, February 07, 2013 3:00 AM
     
     
  • Thursday, February 07, 2013 7:36 PM
     
     

    If you have a client username in the filter, you will only see authenticated traffic. If the connection fails before the authentication process, then you won't see anything in the log viewer.
    That being said, the situation where you can't remove that parameter is not normal behavior. You're also missing one other filter that is usually in there. Looks like your default filter got messed up somehow.

    Try this: close the console and delete (backup - just in case) this file C:\Users\youradministratorname\AppData\Roaming\Microsoft\MMC\msisa

    Then fire up the console again - that should recreate it.

    The Test Rule button is on the General tab of the Web Publishing rule.

  • Thursday, February 07, 2013 9:29 PM
     
     

    I found an issue. in the firewall, the interface 2 for the dmz was set to 10.32.24.2, but in the ip4 config on the rp/tmg server, the gateway was set to .1   

    i changed it to .2, and i could then see port 443 on the external ip was open.  i tried to connect via the android client but still cannot.

    Heres the test:

    the query found nothing, i left the original filters after fixing the mmc and added the new ip, and wifi was off.   then i removed the 'action' filter and tried again, still nothing in the log and i can't connect via the mobile client, although i did get certificate notice and allowed/ok'd it - something i've never received before.   we're getting closer! :)



    • Edited by paulman Thursday, February 07, 2013 10:36 PM edit
    •  
  • Thursday, February 07, 2013 11:02 PM
     
     

    It seems you rule tests out fine. Which means - provided you have entered the correct IP on the filter - that either no traffic is getting to the TMG, or your perimeter NAT device is replacing the original address with it's own.

    Do you see any traffic at all with all filters except the default removed?

  • Friday, February 08, 2013 1:36 AM
     
     

    That's very possible.  I made sure the IP was from today just before the test (my 4g ip changes after i turn off wifi on my phone).

    can you clarify this: 

    Do you see any traffic at all with all filters except the default removed?

    thx

    p

  • Friday, February 08, 2013 2:12 AM
     
     

    In the log filter, remove everything except for the defaults (Log Record Type, Log Time, Action).
    Make sure Log Time is set to "live".

    Try to connect with your mobile device. If you don't see anything, you have a routing problem, not a TMG problem - the traffic is not being sent to/not arriving at the TMG.

  • Friday, February 08, 2013 6:27 PM
     
     

    i got a ton of stuff so i changed the filter slightly to 'allowed connection'  even though this doesn't show as my device ip.   i try to login, get the cert popup on my android and select 'connect'.   but i never get signed in, it just keeps trying.   here's the log entry, you'll see my sip account listed.  i checked the msx device type and it's set to allow greather than 4.x.x.x..   getting closer!   what's our next step?

  • Friday, February 08, 2013 8:03 PM
     
     

    That IP is a Verizon IP, so it probably is your device (you can get your mobile IP address by navigating to www.whatsmyip.org on your phone).

    What you want to do is figure out if TMG is blocking any communication. If not, then your connection problem is not related to TMG, but instead to some other issue, like possibly authentication delegation or possibly even some configuration tweaks on the internal resource.

    Remove the "allowed connection" restriction (you want to find out if anything is getting denied) and add "Client IP -> equals -> your IP address".
    Try to connect and monitor the traffic.

    Another issue I'd be wary about is that in your case you're doing double NATing. I'm by no means a Lync expert and I do not know if this is potentially an issue, but I have seen applications "misbehave" when multiple NAT devices are in the communication chain.

    Again, I'm no Lync expert, but a cursory web search (Keywords: Lync 2010 double NAT) all result in articles that seem to indicate that a Lync Edge box is necessary in the DMZ (Examples: http://jsilverdrake.blogspot.com/2012/04/publishing-lync-with-forefront-tmg-part_26.html and http://social.technet.microsoft.com/wiki/contents/articles/9808.installing-lync-edge-server-in-double-hop-dmz.aspx)

  • Friday, February 08, 2013 8:19 PM
     
     

    That must be my ip because the second i stopped and started the sign in attempts, the logs stopped and started.

    We have an EDGE server in the DMZ already. 

    The screen print below of the log with no filter on 'allowed connection' shows the connection was allowed.   So I'm not sure what you mean by "What you want to do is figure out if TMG is blocking any communication"

    By double NAT'ing do you mean Verizon and our firewall?  


    • Edited by paulman Friday, February 08, 2013 8:32 PM edit
    •  
  • Friday, February 08, 2013 8:31 PM
     
     

    screen cap of latest log

  • Friday, February 08, 2013 8:48 PM
     
     

    Any "denied connection" in there? If not, then your connection problem is not the TMG.

    Double NATing: Traffic is being NATed on your perimeter device (Outside Internet to DMZ) and then again on TMG (DMZ to Internal). That's called double NATing or Double-Hop.

    As mentioned, I'm not a Lync expert, but I'm pretty sure you need to point your mobile device at the Lync Edge box, not at the internal resource directly (meaning the TMG).

  • Friday, February 08, 2013 9:27 PM
     
     
    Thanks for all your help!  i'm going to ask in the Lync forum.  
    • Edited by paulman Friday, February 08, 2013 9:44 PM edit
    •