Sign in
 
HomeProductsLibraryLearnDownloadsSupportForums
Microsoft Forefront TechCenter >
> 
> 
Static routing problem with FTMG

Answered Static routing problem with FTMG

  • Monday, June 14, 2010 11:30 AM
     
     
    Sign In to Vote
    0

    Hello!

    I have a site-to-site VPN configured on 2 Linksys routers with OpenVPN installed. Office A has 2008R2 RRAS, Office B has Forefront TMG (previously, i used them to set up VPN). I can post a network diagram, if necessary, but there is no problem in network topology. Also there is no problem in VPN tunnel itself: no lags, losses etc.

    RRAS (192.168.0/24) and TMG (192.168.1/24) are configured with static routes (I tried all possible ways: via "route add", RRAS mmc and TMG console), also TMG has remote subnet addresses in the Internal network (complete .0-255). Now the most interesting.

    I can successfully PING and TRACERT any location on any subnet and the same time I cannot use any other higher level protocols (TCP, UDP) to connect to remote services on the FTMG segment except the FTMG server itself! Once I add a static route directly on any machine on the "affected" subnet - problem is gone and services are accessible (i can use RDP, RPC, LDAP...). Once I remove it - TCP/UDP is down, but ICMP still works.

    Forefront TMG is suspect for this behaviour, but I can't see where is the bug.

    Valeriy Shevtsov, MCT
     

All Replies

  • Tuesday, June 15, 2010 1:33 AM
     
     
    Sign In to Vote
    0

    "I can successfully PING and TRACERT any location on any subnet "

    Are you saying that you can ping the macheins on the two sites from each other? If yes, could you do a tracert to confirm the path?

    "Once I add a static route directly on any machine on the "affected" subnet "

    What kind of route do you add? To use what as a gateway for where to where?

    I understand your network is somewhat like this:

    Clients A>>RRAS as Router>>Linksys VPN Endpoint>>Internet<<LinksysVPN<<TMG<<Clients B

    If yes, then for the TMG Server, the clients A are a part of external network. I want to know what is the network rule between the external and ClientB network on TMG. Is it NAT or route? If it is NAT, client A will always see the traffic coming from the external IP of TMG and will only be able to communicate with TMG only, via its external IP. Hence, please make sure its a ROUTE type relationship.

    Also, to allow the communication, you can create address range object on TMG, with the IP range of clients A and allow the protocols between the "address range" and client B.

    If you have any spoofing issue etc, check the alerts. It will also give you the Configuration Issues with the address assignements.

    Lets discuss this further once you check the above.

    Regards, Amit Saxena
     
  • Tuesday, June 15, 2010 6:19 PM
     
     
    Sign In to Vote
    0

    Here is the network diagram: link

    I use hardware routers for VPN only, not for internet access (RRAS and TMG handle this). RRAS has a static route to 192.168.1.0/24 via 192.168.0.200 and TMG has static route to 192.168.0.0/24 via 192.168.1.200. I also checked Thomas Shinder article "Net in Net", but all he said was already implemented. Both .1.0 and .0.0 are included in the Internal address range.

    When I do a tracert from RRAS to the DC I see this chain: 192.168.0.200 -> 10.0.0.1 -> 192.168.1.9 (DC). When I do backwards, I see: 192.168.1.1 (FTMG) -> 192.168.1.200 -> 10.0.0.2 -> 192.168.0.7 (RRAS). This works despite of static route entered on DC or not. But once I do a "route add" on DC, i can immediately connect to it via RDP from RRAS (other services like LDAP works too).

    Valeriy Shevtsov, MCT
     
  • Wednesday, June 16, 2010 2:02 PM
     
     
    Sign In to Vote
    0
    What is the route that you are adding? ALso, I think its that route that is required to fix this anyways.
    Regards, Amit Saxena
     
  • Wednesday, June 16, 2010 9:12 PM
     
     
    Sign In to Vote
    0

    route add -p 192.168.0.0 mask 255.255.255.0 192.168.1.200 - on FTMG

    route add -p 192.168.1.0 mask 255.255.255.0 192.168.0.200 - on RRAS

    I also tried to add routes via MMC consoles, no luck. Actually, it was the first way I did this.

    Valeriy Shevtsov, MCT
     
  • Saturday, June 19, 2010 6:49 AM
     
     
    Sign In to Vote
    0

    route add -p 192.168.0.0 mask 255.255.255.0 192.168.1.200 - on FTMG

    route add -p 192.168.1.0 mask 255.255.255.0 192.168.0.200 - on RRAS

    I also tried to add routes via MMC consoles, no luck. Actually, it was the first way I did this.

    Valeriy Shevtsov, MCT


    what do you mean by "mmc consoles" ?

    yes, the prpoer way of route management for FF TMG is using its console.

    it doesn't like manual manipulation like "route -p ...."

     
  • Saturday, June 19, 2010 9:25 PM
     
     
    Sign In to Vote
    0
    I mean FTMG and RRAS consoles - they are usual MMC actually. It doesn't matter which way I add a route - via "route add" or GUI, the only difference is that FTMG gui-added routes are added twice with different metric (when you do a "route print").
    Valeriy Shevtsov, MCT
     
  • Saturday, June 19, 2010 11:49 PM
     
     
    Sign In to Vote
    0

    Hi Valeriy,

    If routing is an issue, nothing will work, be it ICMP or any other protocol. Now in the diagram, I do not see any DC so I still have my doubts.

    Take a live logging on the TMG. It will tell you why is it blocking it. No one can answer that question better than the TMG itself :)

     

     

    Regards, Amit Saxena. Keep Walking!
     
  • Sunday, June 20, 2010 3:57 PM
     
     
    Sign In to Vote
    0

    I did a live logging with no luck, FTMG says "packet allowed" and "internal implicit route will be applied".

    Valeriy Shevtsov, MCT
     
  • Monday, June 21, 2010 9:32 AM
     
     Answered
    Sign In to Vote
    0

    I finally found the bug, it's completely ISA/FTMG issue, not mine.

    http://support.microsoft.com/kb/888042
    ====================
    When a client computer that is behind Microsoft Internet Security and Acceleration (ISA) Server 2004, Microsoft ISA Server 2006, or Microsoft Forefront Threat Management Gateway, Medium Business Edition sends traffic to another internal computer, the ISA Server or Microsoft Forefront Threat Management Gateway, Medium Business Edition computer may drop the traffic. ...

    This issue occurs even when the server has valid routes to both source and destination subnets. In this situation, the TCP connection request (SYN) from the client to the server bypasses ISA Server or Microsoft Forefront Threat Management Gateway, Medium Business Edition. However, the SYN-ACK packet is routed to the server and dropped with a TCP_NOT_SYN_PACKET error. In short, both sides of a TCP session must go through the ISA Server or Microsoft Forefront Threat Management Gateway, Medium Business Edition computer.


    This behavior may not occur with User Datagram Protocol (UDP) traffic, or Internet Control Message Protocol (ICMP) traffic.
    ====================

    I'll research how to fix this without modifying default gateways or infrastructure. 

    Valeriy Shevtsov, MCT

     
  • Wednesday, June 23, 2010 4:07 PM
    Moderator
     
     
    Sign In to Vote
    0

    HI Val,

     

    What the above link is saying is that traffic is being re-routed through a different path than its original path. As the article mentions that it doesnt affect ICMP or UDP traffic because they are not stateful. TCP on the other hand is stateful and TMG will do stateful inspection to ensure that traffic is re-routed the same way it was sent.

    The reason why it works from your client when you add a static route is because then tre traffic goes back via the same path. without the static route it uses its gateway to send the traffic back because in a route relationship the traffic will appear to come from the actual client so the host must respond back to the client directly if it knows how to else it will send it to its default gateway which will then in turn send the packet back via a different route.

    This is not a bug but a behavior by design and a security feature (stateful inspection). to fix this you need to ensure that the client knows to send the packet back u sing the same route or your router needs to be aware to send the traffic back via your RRAS for the route TMG subnet and vice versa.

    HTH

    Mohet

     
  • Thursday, June 24, 2010 10:48 PM
     
     
    Sign In to Vote
    0

    Well, as far as i found on the Internet, it worked on ISA until 2004 SP1 where ICMP redirect message was replaced with simple packet drop.

    I'm curious, why FTMG correctly detects that destination is on the Internal subnet (if configured, of course), stateful inspection thinks "it's internal, so it must be routed directly" and then the packet is dropped leaving the client unaware of correct route. Why don't add an option to answer with ICMP redirect when
    a) both source and destination are on the Internal and
    b) the FTMG has a valid route?

    There also maybe a fix for the clients that directs them to accept ICMP redirect messages only from default gateway. Sounds quite easy and secure, isn't it?

    Valeriy Shevtsov, MCT
     
  • Tuesday, June 29, 2010 11:50 PM
    Moderator
     
     
    Sign In to Vote
    0

    Hi Valeriy,

     

    Stateful inspection doesnt change the packet behavior or make the decision on how routing happens. All that is handled by windows and firewall engine. ALl stateful inspection does is verify if the packet is using the same route to some back as it used to go out. The behavior has been the same since ISA 2004 RTM. Here is a simple example:

    Example A
    Client A sends the traffic to ISA and ISA sends the traffic to Server A. Now Server A thinks he can get to client A without going back through ISA and sends the packet via a different route. At the point ISA is waiting for a reply and doesnt get one hence it breaks the connection.

    Example B
    Client A sends the traffic to ISA and ISA sends the traffic to Server A. Now Server A thinks he can get to client A via another router and sends the traffic to that router and that router sends the traffic to ISA. In that case ISA sees that got a response from a different address that what it sent the traffic to and will drop the connection.

    Both these behaviors have been same since ISA 2004. Regarding changing of the packet, if the default relationship is set to Route then we dont change the packet in any way. If you set the relationship to NAT then ISA will change the IP header. In that case the server I am trying to ping to should only have a route till TMG and not to the end client but traffic will only work from inside of the NAT going out.

    HTH

    Mohit

     
  • Wednesday, June 30, 2010 10:49 PM
     
     
    Sign In to Vote
    0

    I have had the same problem.

    This issue may occur when packets in one direction go through a route that does not involve ISA Server, and packets in the other direction go through ISA Server.

    More details here :

    http://technet.microsoft.com/en-us/library/cc302656.aspx#ClientConnectionsFromARemoteSubnetDenied

    PaulP