none
Different subnet, no acces but simulates ok

    Domanda

  • Hello,

    i have a TMG2010 that has behind it's LAN card several different subnets, right now they're all using class B masking for example:

    172.16.x.x

    TMG has 172.16.0.10 /16

    the offending stations use the 172.16.2.0/16 subnetThe problem is that i can't access the TMG from a portion of those stations, ping doesn't even responds.

    Yet from two servers in that subnet(172.16.2.1 and 2.2) it works back and forth correctly.

    If i do a traffic simulation using the source IP of the offending stations, it gives all-OK green.

    What gives?

    lunedì 18 giugno 2012 15:33

Risposte

  • i found the problem after reviewing the logs:

    The failing network was triggering the default block for SMB and ping, but the old LAN was not and instead triggered system rule 34 "management stations".

    so i checked that group after some digging and indeed, the only listed range was 172.16.0.x, so i added the entire of the 2.x network, applied and now it's working perfectly.

    • Contrassegnato come risposta Eliminateur martedì 31 luglio 2012 20:36
    martedì 31 luglio 2012 20:36

Tutte le risposte

  • Hi,

    please check if these clients which cannnot be contacted have the TMG Server as their Default Gateway and that these subnets are part of the IP address ranges in the TMG network object INTERNAL


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    lunedì 18 giugno 2012 18:25
  • Marc,

    i've already checked all that, they're in class B subnet, they have the TMg as default gateway, etc

    lunedì 18 giugno 2012 19:28
  • Hi,

    Thank you for the post.

    Please check if the subnet is add to TMG internal network like Marc said. If there any router between this subnet and TMG server? what is live logging tell?

    Regards,


    Nick Gu - MSFT

    martedì 19 giugno 2012 04:38
  • The servers that do work, do they have any manual routes added that would enable them to communicate with TMG? Or the other way around (tmg has specific routes)...

    Does TMG produce any alerts? Specifically those that warsn about a difference between routingtable and local address table. In the Event Log those would show as 14147 events.


    Hth, Anders Janson Enfo Zipper

    martedì 19 giugno 2012 08:32
  • everything is connected to the same lan, nothing between them, it's already on the internal network.

    There are no manual routes anywhere, what's more, why is it working for only 1 stations in that range?

    there's no need to have any manual route when you're all in the same lan and under the same subnet range

    Hmmm i have a 14147 event, but it talks about the external network, that the adapter "internet" has intervals that don't comply with the external netowrk, and it lists the LAN IPs, wth???

    still need to check the live logging


    martedì 19 giugno 2012 18:56
  • From the above, I wold - as you say - look at live logging. I would also verify the address table for the internal LAN. Do you have additional IP addresses on the external interface that are internal?

    Do note that external and internal has to be on different subnets [period]. Otherwise it won't work. Your gateway should be on your external card only. No default gateway on internal.


    Hth, Anders Janson Enfo Zipper

    giovedì 21 giugno 2012 08:46
  • external does not overlap and has only one address.

    in fact i've traced the problem a bit more by simulating traffic for SMBfrom the "old" LAN:

    if i put 172.16.0.x as origin it allows the access with a system rule from trusted internal servers

    but if i put the 172.16.2.x as origin it fails with default deny!

    how can i add the 2.x to the trusted networks?

    also, how can i fix the 14147 events?

    martedì 31 luglio 2012 18:58
  • i found the problem after reviewing the logs:

    The failing network was triggering the default block for SMB and ping, but the old LAN was not and instead triggered system rule 34 "management stations".

    so i checked that group after some digging and indeed, the only listed range was 172.16.0.x, so i added the entire of the 2.x network, applied and now it's working perfectly.

    • Contrassegnato come risposta Eliminateur martedì 31 luglio 2012 20:36
    martedì 31 luglio 2012 20:36