Multiple Wan Lines, 1 gateway

ashrobbo

ashrobbo

ashrobbo

Associate
Joined
3 May 2009
Posts
805
Hi All,

We are currently looking at a UTM Device to perform some tasks in place of our current outdated and old systems.

We run Exchange 2007 with symantec mail security (eurgh!) for our anti-spam needs.
We have 2 Firewalls protecting our multiple internet lines, and we have just had a 3rd line installed.

We currently have 1 Cisco pix 506E on each line, and a temporary untangle box on the new line.

We are looking at purchasing a sonicwall 2400 to take care of anti-spam duties amongst web filtering etc.

Currently our exchange server is going out on 1 gateway (1 line) our domain DNS MX records points to one of our static ip's (217.xx.xx.xx) on our email line.

We also have a 'Services' Line with 5 static IP's in the 80.XXX.XXX.XXX Range and this is the gateway of some of our web servers.

we now have a 50mb internet line with another 5 static iP's in the 62.xxx.xxx.xxx range

Now....

With the UTM I think we can plug them all in, ditch the Pix's and load balance the traffic over 2 of the lines and have the other email line dedicated

So in theory could I have one of the IP's on each interface (80.xx, 217.xx, 62.xx) pointing to the same server, so if a line is down the server is accesible on another ip? (e.g an MX record)

I would also like to force The mailserver to use the email line to send mails out and not use the other lines

Would i do all of this through NAT Statements?

Diagrams attached :)







Thanks,

Ash
 
Last edited:
Yup, that 2nd diagram would be fine on a SonicWall NSA 2400. I have three connections coming into our office NSA 2400, each one on a different subnet.

You can use route policies, so can direct SMTP traffic from your mail server down a particular WAN interface. You can put a probe on that route, so should the line go down, the route is disabled.
 
#Chri5# said:
Yup, that 2nd diagram would be fine on a SonicWall NSA 2400. I have three connections coming into our office NSA 2400, each one on a different subnet.

You can use route policies, so can direct SMTP traffic from your mail server down a particular WAN interface. You can put a probe on that route, so should the line go down, the route is disabled.
Click to expand...

I've actually just received our trial unit, so im going to try and set up some proper tests tomorrow.

Superb info, thanks very much, anything else i should know about sonicwalls? I did have a play with the content filtering and trying to filter facebook, which worked, but only when i logged out of the web interface?!?! if i was logged in no filtering occured... hmm
 
You can be as specific as you want.

So you could have routing rule which effectively says "Any SMTP traffic from anything on the X0 interface, send via X?". Or you could say "Any SMTP traffic from a group of IP addresses {an address object group} send via X?", or replace the address object group with a single IP (server).
 
Cheers for the info Chris,

Ive been playing about all day and im fairly impressed with the box and the tools. Been fairly easy to setup, ruloes and address objects are very good.

Although..

Ive downloaded viewpoint and its beena bit of a nightmare, managed to get it reporting but it only shows IP instead of username even though i have SSO active.

Just resyncing the logs across. Its a shame i cant see what user has been to what website straight from the sonicwall.
 
SSO can be a bit of a pain to configure for the first time round! We manage anything up to 100 Sonicwalls and have SSO configured for most of them.

The thing that usually gets missed is the firewall rule that gets applied to the group configured in the SSO config.

If you think SSO is configured correctly you can do tests from the Sonicwall and from the SSO agent itself to see if the agent is capable of resolving users logged in to workstations and servers
 
Phal said:
SSO can be a bit of a pain to configure for the first time round! We manage anything up to 100 Sonicwalls and have SSO configured for most of them.

The thing that usually gets missed is the firewall rule that gets applied to the group configured in the SSO config.

If you think SSO is configured correctly you can do tests from the Sonicwall and from the SSO agent itself to see if the agent is capable of resolving users logged in to workstations and servers
Click to expand...

All the tests work ok, ive got the directory connector installed on my workstation, but I dont really uinderstand the point of ldap+local vs just ldap, can you explain?
 
I won't try to explain the point as I only kinda understand it myself... but here is how ours are configured

We use LDAP + Local users for the authentication method

When you configure the authentication (LDAP + Local Users) you need to set a group on the LDAP Users tab. We use the 'Everyone' group but afaik you can choose one.

All you need then is a LAN > WAN Firewall rule that specifies HTTP and HTTPS outbound traffic as allowed and it needs to be applied to the 'Everyone' group (or whatever you use). This is regardless of whether or not all outbound traffic is allowed.

Without that firewall rule the SSO agent won't resolve usernames of outbound traffic.
 
Probably a good thing... The few times I've had to deal with Viewpoint weren't pleasant :/


We use GMS to manage and create reports from all our Sonicwalls and that works ok but it's not really a viable option for people with a one or two Sonicwalls.
 
Not overly familiar with Sonicwalls but this is easily done with NAT, better approach would be to use policy based routing should you want to failover any services to other lines in case of WAN failure.

Normally prefer to use Cisco but for a cost effective all in one UTM device Fortinet would be my choice.
 
You must log in or register to reply here.
Back
Top Bottom