Forefront Threat Management Gateway

tmg-sonicwall.jpg

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,...it would not involve the TMG.  The TMG is only there for devices "out in Internet Land".

Thank you for the help.

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.

I do :)

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
http://technet.microsoft.com/en-us/library/gg195748.aspx
http://technet.microsoft.com/en-us/library/gg425882.aspx
http://technet.microsoft.com/en-us/library/gg398478.aspx

The reference architecture from microsoft on lync can be helpful

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

Another on TMG and Lync
http://jsilverdrake.blogspot.sg/2012/04/publishing-lync-with-forefront-tmg-part_26.html