04-04-2012 08:42 AM - edited 03-11-2019 03:50 PM
Hi,I need to introduce a TMG inside one of our branches networks so the default internet traffic pass through TMG and then to the ASA as per the new standard. I am new to TMG and playing with few designs on how to set TMG up as painless as possible in to the production environment.
My question is this:
As of now we have ASA firewall that connects with a trunk to our core switch. Vlan x.x.x.x used as a core vlan that the core switch and ASA being managed through also hosting few lync servers. Right now ASA does the NATing for outgoing internet traffic and several static NATs for servers on VLANx.x.x.x What i need is to put a TMG in between ASA and the core switch so all traffic bound for internet will pass through the TMG while still being able to keep ASAs internal interface on VLAN X.X.X.X without being worried about routing issues.
My Idea is to create a new L3 vlan on the core switch (192.168.x.x) and assign it to the external interface of the TMG, then give the Internal Interface of the TMG an IP address within the X.X.X vlan. But without PBR on the core switch i will cause routing issues if i will put a default route on the coreswitch for all 0.0.0.0 traffic to the TMG Internal and on the same switch a Static route for all incoming traffic from the ASA towards the External TMG. And if i will extend that 192.168 vlan in to the Trunk towards the ASA i will have to lose the ASAs interface on vlan X.X.X as to not cause routing issues with traffic going through ASA towards the TMG. So i am in a pickle here....
how do i preserve ASAs X.X.X interface and route traffic through it to TMG and back ?
I also will have to disable NAT on TMG so all NAT will be done on the ASA and TMG will just be routing all traffic from ASA towards the X.X.X vlan through the Internal Int. and routing all Internet bound traffic towards ASA throught External interface. I will also have an issue of spoofing if i will go with my initial config as vlan X.X.X.X will be seen on both internal and external interfaces unless i trunk it all the way to ASA.
any ideas will be appreciated.
04-05-2012 09:32 AM
If you don't need the X, Y, and Z vlan's to be firewalled you can move them back into the core switch as normal routed vlan's. If you do need one or two of those vlan's to be firewalled you can keep them on the ASA but you won't be able to route their Internet traffic through the TMG - just the internal network(s). You can either put TMG between ASA and core switch which forces you to move X, Y, and Z vlan's to core switch or move TMG between the ASA and the Internet (isn't recommended).
Another solution is to straddle the DMZ and internal networks on the TMG giving it multiple legs. The DMZ leg will connect directly to a DMZ switch feeding the DMZ servers. For this option, your DMZ servers will point their default gateway to the TMG server not the ASA. The ASA will route to the TMG for the DMZ servers on the internal interface. Something like this...
04-05-2012 03:31 PM
thats where the problem lies...
i have to have Y and Z vlans routed by ASA (secure segments) and ASA has to have a leg ( sub int) in X vlan as if i need to bypass TMG to staticaly route and staticaly NAT directly to servers in X vlan....
so i am tied by policies of the company and not really able to "move" many things around.
I still have to make sure all default internet traffic to have the following flow - Users -> core switch - > TMG --> ASA
while making sure that i have access to ASA ( even throught management interface) from other networks that are connected or routed to X vlan by a separate connection ( MPLS)
so in best case scenerio i can connect management interface to vlan x and cut the vlan x leg off the ASA .. but then i will have two identical routes on ASA:
route (TMG vlan) 10.0.0.0 0.0.0.0 towards the TMG IP
route (management) 10.0.0.0 0.0.0.0 towards the CoreSwitch.
that brings one more question ... will the management route create my routing issues with my traffic or will the management-only take care of it and will only be used to access that interface?
04-05-2012 04:06 PM
Your routing suggestions aren't going to work. The management port is what it is a non-routed port just for directly connected management of the firewall - unless you removed management-only from it.
You can achieve what you're talking about by doing the following design, granted your Y and Z server/LAN traffic will traverse TMG but there's no way around that unless you have a Cisco router in the mix doing some fancy policy based routing. You can still NAT Y/Z servers through ASA and reach the same servers through TMG (without NAT) for internal connectivity and management.
Another solution is you can move Y and Z Servers to their own leg on the TMG but you'll be managing two sets of firewall rules (ASA + TMG) for these servers.
04-05-2012 04:07 PM
my ascii drawings didn't come out right:
top drawing should show Y/Z Servers hanging off ASA
bottom drawing should show Y/Z Servers hanging off TMG
04-06-2012 07:09 AM
i know that what ever traffic that is going to need to reach my users will have to pass throught TMG if i dont have PBR on my CSW, and i need Manangement int on ASA justfor that .. to manage it but what i encountered was that people comming from networks that are not directly connected to the core switch cannot reach the ASA by its Management Interface unless i put a route management x.x.x.x/24 next hop core switch IP on X vlan. ( as in ASA doesnt know what lies behind the core switch on management and tries to push all traffic throught the TMG.
So my question is if i have two routes on ASA one on TMG vlan and one on management interface that are practicaly the same route .... will ASA know not to push any traffic but the management through it so it wont cause any issues for me but mgmt int will still be available from remote networks? ( by remote i mean MPLS behind the core switch , and not through vpn/ASA)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: