Link to home
Start Free TrialLog in
Avatar of HFComm
HFCommFlag for United States of America

asked on

Forefront Threat Management Gateway

I am evaluating setting up TMG as a reverse proxy for Lync. Right now we have a SonicWALL as our perimeter firewall and only have OWA setup to external users. I do not want to route all outbound traffic through the TMG and would prefer to keep everything going through are SonicWALL as we have many VPN tunnels set up between ours and our clients SonicWALLS.

My though is to place the TMG between a second interface on our WAN router and then connect it to our switch.

Is this a viable setup? Is it supported? I have been trying to search to find a similar solution but I can't seem to find anything (or at least ask the right question)

I am attaching a picture of how I want to set this up.

Avatar of HFComm
Flag of United States of America image


Avatar of pwindell
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of HFComm


Would I be right in assuming I would leave the default GW on all of our workstations to point towards the Sonicwall and then I could point the servers default GW to the TMG and then just add static routes on the servers for our VPN tunnels to route any traffic from them through the Sonicwall?

I am assuming it only needs to go through the TMG if it is for a mobile non-vpn client correct?
Nothing "points" to the TMG as far as gateways are concerned.  Keep the LAN's Routing Scheme consistant that way it is.

That's why you set the Rule Properties as I said.

Now if you have a device directly on the LAN then it would use Lync directly, would not involve the TMG.  The TMG is only there for devices "out in Internet Land".
Avatar of HFComm


Thank you for the help.
Avatar of btan

The proxy is there for the front edge lync servers for remote users.  TMG serve that purpose so as long as thwart user has done the sue authentication. Or vpn check, the traffic can just pass on to TMG. I am just thinking that the sip connection will need to make sure that the source iphone of remote client are maintain for sip comes.
Will be interested to hear the outcome of this approach.
Publishing common things this way works fine,...I just don't know much about Lync itself.
So what do you think?  :-)
Seen a lot of issues with LYNC and TMG publishing/other firewall combinations, let alone having potential for multiple routes of the various protocols - it is not just proxy traffic as you know when LYNC is involved and the potential for split routes is present.

I would suggest that the question asker ensures that SP2 and the additional interim rollups are all deployed to give it the best chance.
True, only protocols (HTTP, HTTPS) coming in through the Web Publishing Rule will respond back out the TMG,...anything else would be a split path.  So maybe the Dfg of the effected Server should be pointed at the TMG, assuming that doesn't break something else, then add static routes on that same server to cover other segments (VPN or otherwise).

If it were me (it's not of course), but if it were,..the TMG would be the Default Path and the Sonicwall would be eliminated.

I actually have a Sonicwall here along with our ISA,...but the ISA is in the primary role instead of the Sonicwall,...the Sonic wall does nothing but waste electricity for the most part.  I have a few processes that use the Sonicwall based on Routes in the LAN Router according to certain Destiantion addresses or subnets,...and that is of course an outbound only thing,..nothing inbound.

Isn't SIP one of Lync's protocols?  Isn't SIP one of those that sometimes you have to use the Application Filter and other times you can't use the Filter,....and hard to tell when to do one or the other?
My though is to place the TMG between a second interface on our WAN router and then connect it to our switch.

It would not be a second interface,...a second interface implies a new subnet (which doesn't exist).  It would be the same interface as the Sonicwall,..even if that means adding a Switch between the WAN Router and Sonicwall/TMG

Personally, I'm starting to think TMG is a very bad idea here,...with no measurable benefit even if you get it to work.  So either forget the TMG and leave things as they are with the Sonicwall or just replace the Sonicwall with the TMG,...but in the end,...have only one Firewall,...pick one.
That would have been my approach.
Agree better not to complicate with so *much FW*. FW should serve as your reverse proxy where possible

The firewall will normally be the default gateway to the Lync Edge servers and if load balancing is needed, the default gateway point back to the LB. The LB default gateway points to the FW as default gateway.

Typically users will hit the load balancer on their first incoming connection and get load balanced, but if a user gets invited to a media session that has started on an Edge Server, the invite they receive will point them directly to that server. NAT awareness was built into Lync 2010 to help in environments in which Edge Servers are deployed behind NATs. By enabling the NAT awareness, Edge Servers will refer clients to their respective NAT address in order to route the users in correctly.

There is practices from Microsoft on lync
The reference architecture from microsoft on lync can be helpful