Welcome to ISAserver.org
Forums |
Register |
Login |
My Profile |
Inbox |
RSS 
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Network redesign, diagram included
|
Users viewing this topic:
none
|
Logged in as: Guest
|
Login  | |
|
Network redesign, diagram included - 6.Aug.2008 10:24:09 AM
|
|
|
pyro
Posts: 3
Joined: 6.Aug.2008
Status: offline
|
Hello,
I'm now integrating a branch location, requiring DC to DC communication. The HQ has 2003 SBS with ISA, Exchange and now needs to publish OWA. I want to use ISA's granularity to do so. Are there practical concerns (except the obvious) of publishing OWA directly from SBS? Any alternatives?
Recently, a PC on the network got a trojan and started sending a lot of SMTP. We have proper GFI ME coming in, with NOD32 XMON and centrally managed NOD32. This particular machine was a personal machine the employee brought in, with compromised external email Outlook. I've kind of been ignoring the internal>external network control in such a small shop (around 15 sales staff, 10 office) and aren't using end-to-end content control through the firewall. Generally, end devices can go out as they please but are intelligently managed themselves. Obviously, this doesn't work if someone brings their own machine.
As for the network design, so far, the branch and HQ are connected by Sonicwalls, with the HQ Sonicwall being ahead of the ISA and the branch using some published services in the Sonicwall-to-ISA DMZ without a branch DC. Would it be recommended for everything to heavily managed, as on the Enterprise level, with heavy logging and direct content management of data through the firewall itself? MAC-based access control though the firewall? Through the switch? There aren't a lot of regulatory/legal/audit hassles, but what is the advised level of security/trackability for a 25-user company?
More specifically, I am planning on using the following design, for the reasons written in the diagram. HQ Sonicwall: VPN to the branch into the LAN segment, with the OPT interface serving as the DMZ segment to publish OWA from ISA. The idea is that the LAN interface is basically reserved to connect the branch by IPSec VPN -- the LAN machines will go through ISA (GFI Webmonitor also installed for HR). The Remote VPN clients will terminate in the Sonicwall OPT (DMZ) and have limited services. The "Public" WiFi for external customers of ours will go into the Sonicwall OPT (DMZ), configured (perhaps by ACL) so the Remote VPN clients and WiFi users don't talk. I'm aware that the diagram looks in the "nightmare scenario" that a novice may configure to bypass the ISA, but of course the three interfaces on the Sonicwall have independent ACL and routing, so it is actually a tri-homed firewall, with the LAN segment going directly into the LAN (however if the Sonicwall is truly compromised, the promised of DMZ protection doesn't exist). How does this seem? Anything I'm missing?
Here is my new diagram with concerns/ideas. Any thoughts/observations are very appreciated. Thanks.
(Pardon the diagram -- no Visio here, had to use Photoshop.)
< Message edited by pyro -- 6.Aug.2008 10:29:43 AM >
|
|
|
|
|
RE: Network redesign, diagram included - 6.Aug.2008 2:37:29 PM
|
|
|
pwindell
Posts: 782
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
|
The ISA is neutralized and made worthless by the "LAN" link going around it into the LAN Int of the Sonicwall.
ISA should plug into the LAN Int of the Sonicwall (not the Opt Int). If the NAT Relationship between the LAN and the DMZ is too restrictive and too much a hinderance then switch the Relationship to "Routed". The ISA Access Rules will still control traffic flow between the LAN and the DMZ regaurdless of NATed or Routed.
_____________________________
Phillip Windell
www.wandtv.com
|
|
|
|
|
RE: Network redesign, diagram included - 6.Aug.2008 2:51:01 PM
|
|
|
pyro
Posts: 3
Joined: 6.Aug.2008
Status: offline
|
The "LAN" link is highly secured and will basically allow only VPN traffic to the branch. LAN will not NAT/Route out through the Sonicwall WAN (and the Branch Sonicwall won't allow it either). The ISA is the gateway OUT (LAN>ISA>OPT>WAN>Internet).
What do you mean, it's neutralized? I'm not sure if I made it too cumbersome to read and you're just saying that looking at the logical diagram?
The problem is that I need a direct VPN to the branch for the LAN segment, but I also want to preserve a DMZ for publishing. Would you recommend another way? Are you saying that this is physically bad, should the Sonicwall be compromised?
|
|
|
|
|
RE: Network redesign, diagram included - 6.Aug.2008 3:09:57 PM
|
|
|
pwindell
Posts: 782
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
|
The "LAN" link is highly secured and will basically allow only VPN traffic to the branch. LAN will not NAT/Route out through the Sonicwall WAN (and the Branch Sonicwall won't allow it either). The ISA is the gateway OUT (LAN>ISA>OPT>WAN>Internet).
What do you mean, it's neutralized?
I mean just that. You could remove ISA completely run the LAN into the LAN Int of the Sonic Wall and run the DMZ off of the Opt Int and you would accomplish the same thing. The ISA is accomplishing nothing other than creating excessive needless complexity.
Give ISA a real reason to exist.
Configure it like I said.
Use a Routed Relationship between the LAN and DMZ (for the sake of the VPN Clients). If not for the VPN Clients terminating in the DMZ you could have just run a NATed Relationship which is the default.
Don't use the Opt Int on the Sonicwall at all.
ISA Access controls will regulate traffic between the DMZ and the LAN which will include the VPN Clients who "terminated" into the DMZ.
If you don't trust ISA to be secure and to do its job, there was no point in buying it.
You asked for thoughts,...
_____________________________
Phillip Windell
www.wandtv.com
|
|
|
|
|
RE: Network redesign, diagram included - 6.Aug.2008 8:49:29 PM
|
|
|
pyro
Posts: 3
Joined: 6.Aug.2008
Status: offline
|
The real questions is: How do I Site-to-Site VPN cleanly from the Branch LAN, through the Sonicwall?
ISA still has a function: high-level filter-based OWA security, better logging for the clients, SMTP filter, GFI Webmonitor integration.
I am inclined to imagine the Sonicwall as two firewalls logically (single point of failure). What if was using your topology, with a SECOND SEPARATE public Sonicwall plugging into the LAN segment with NO SERVICES to the outside except for IPSec Site-to-Site, and NO route out though the WAN, only VPN Site-to-Site communication would that still neutralize the ISA?
As is stands, it's set up your way. I need the following change:
1) Direct, open communication of the HQ and Branch LAN segments (not Branch>DMZ). I would have to do pass Branch IPSec through the Sonicwall and forward it. The Sonicwall NATs in -- another problem, NAT-T doesn't seem to work. To pass IPSec through the Sonicwall to the ISA seems like an uglier, riskier solution. What do you think?
< Message edited by pyro -- 6.Aug.2008 8:51:50 PM >
|
|
|
|
|
RE: Network redesign, diagram included - 7.Aug.2008 9:33:00 AM
|
|
|
pwindell
Posts: 782
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
|
What if was using your topology, with a SECOND SEPARATE public Sonicwall plugging into the LAN segment with NO SERVICES to the outside except for IPSec Site-to-Site, and NO route out though the WAN, only VPN Site-to-Site communication would that still neutralize the ISA?
A separate second Firewall dedicated to only creating/maintaining a VPN link is a fine excellent idea and is what I would rather do if I had the choice. It would sit directly on the LAN edge facing the Internet (no DMZ) and just do the VPN and nothing else.
This is in fact what we do here with a separate dedicated Cisco ASA. We use it to link our TV Station (Illinois) to another "sister" TV Station (Kentucky). My LAN has multiple subnets so there is a regular LAN Router in the logical "center" of the LAN (nothing to do with the Internet) and this router makes all the routing decisions for the LAN from its "central" location,..so I just have a Static Route on it that just tells it to use the ASA as the "gateway" for all traffic destined for the IP Segment used by the Kentucky Station. The ISA and the SonicWall both have the Kentucky Station's IP Range added as a "local/internal" Range so that they do not interfere with that traffic. It is so trouble-free that I often forget that it is even there.
As is stands, it's set up your way. I need the following change:
1) Direct, open communication of the HQ and Branch LAN segments (not Branch>DMZ).
In that configuration keep in mind that your VPN(s) are terminaing in the DMZ. If you really set it up the way I suggested then the relationship between the DMZ and the LAN is "routed" instead of "NAT'ed". This means it is just normal simple Layer3 Routing that moves traffic between the DMZ and LAN. The ISA Access Rules (if done properly) would still maintain whatever restrictions you wanted. Your Cisco ASA would need a static route to tell it to use the ISA's External IP# as the "gateway" to get to the LAN segments. The LAN Segments would already know how to "get there" so there is nothing to do there.
_____________________________
Phillip Windell
www.wandtv.com
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
Printable Version
