[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 172
  • Last Modified:

Assistance with setting up network with firewall

Dear Experts,

I am designing a network and have the following hardware to work with:

1 x Netscreen 25 Firewall
2 x Cisco 1900 Switches
1 x Cisco Router with SDSL WIC

The requirements are:

- 5 servers (need to be accessed externally)
- 10 internal hosts
- I also need to terminate an IPSec tunnel

Could you suggest an addressing scheme for these and suggest how to split them up...

For example, do I put the servers in a DMZ?

Any help would be greatly appreciated.

Thanks

Nick
0
nkewney
Asked:
nkewney
  • 3
  • 3
2 Solutions
 
stsonlineCommented:
If I were laying out this network, I'd use two internal networks - one INSIDE and one DMZ. For clarity of troubleshooting I like to clearly identify my DMZ, so I'd use something like 192.168.10.0 /24 (255.255.255.0) for the DMZ and maybe 172.20.1.0 /24 for my INSIDE network. This gives you lots of room for growth on either network and will make troubleshooting easier, since you immediately know if it's a 192.168 IP it'll be a DMZ address and a 172.20.x.x will be INSIDE.
0
 
stsonlineCommented:
BTW, your available IP addresses are referenced in RFC1918 - it gives you the private IP ranges that are authorized for internal networks... 10.x.x.x /8, 172.16.0.0 thru 172.31.255.255, and 192.168.x.x.
0
 
nkewneyAuthor Commented:
Thanks stsonline...

In terms of the servers... I want to be able to have my internal clients connect to the domain and have them accessible outside also with external IPs.

How would you approach this (the servers have two network cards)

Thanks

Nick
0
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 
nkewneyAuthor Commented:
Thanks stsonline

Yes I'd like to have the internal clients use the servers as domain controllers. Should I put everything in local?

Nick
0
 
stsonlineCommented:
Put your domain controllers on the local (INSIDE) network. Only servers providing Internet-accessible services (like HTTP, FTP, email) need to reside on the DMZ segment.

Are you planning to give each internal system an external IP address? Unless this is absolutely necessary for an application or service, why not "hide" all your internal clients behind a single external IP? It's a lot safer and preserves your external IPs for systems and services that require them.
0
 
ccreamer_22Commented:
use the 10.x.x.x/8 network for your trusted side.
I suggest not going over a /24 bit mask for each vlan.
use the 172.20.0.0 for your dmz addresses.
put the netscreen in nat mode (should be by default) so that when it goes out, it is seen as your untrust interface.
put your web server, ftp, and an owa box with some kind of mail virus scanning software and spam blocking software in your dmz
put your exchange box in your trust zone along with your domain controller and any other internal service such as VoIP, etc.
put your switches into a stack and configure 4-6 ports (however many you need for DMZ servers)  as a sperate vlan that does not have access to the rest of your vlans. This will be your dmz vlan.
The only thing that I can think of that you would want to use both ethernet cards for your setup is possibly a RRAS server for VPN access. set one card up in the dmz and allow pptp and gre to that server only. Set the other card up in your trust zone and set up dhcp for the vpn's on your DC. Other than that, I would only set up a computer on the network with 2 nic cards for intrusion detection, like snort. Other than that, 2 nic cards for the same machine can make administration very rough. Try to keep it as simple a plan as possible. Map out and document everything.
0
 
nkewneyAuthor Commented:
Great help. Thanks.
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now