The best answer will be to ask your ISP to either exchange your modem-router combo device for a modem-only device OR see if they can switch it into Bridge mode (where it becomes only a modem and no longer acts as a router). [I have a Cisco modem-router device from my cable ISP that is like that, I called them and they did something on their end then had me reboot it and it was no longer a router]
If you CAN'T do that (or if you need to get up and running fast) then you CAN connect your SonicWALL behind the modem-router device, it will be double-NAT. Some services will be less happy about that but most won't care.
Just configure X1/WAN with an IP on the 10.0.0.0/24 subnet. Your LAN clients (on 192.168.168.0/24) will be NAT'd by the SonicWALL to a 10.0.0.x IP and then NAT'd again by the modem-router device to your actual public IP.
For outbound this isn't an issue. For INBOUND you will need to open ports on your modem-router (pointing to your X1/WAN IP) as well as create NAT rules on your SonicWALL. Or you can look for a "DMZ" option in the modem-router which forwards all ports to the specified IP (basically a wide-open ANY/ANY/ANY NAT rule) -- common on consumer grade routers.
Note: Some of these modem-router combo devices (which, to be honest are not great, and not designed for business use) will only perform NAT/pass-traffic for IPs it has assigned by DHCP, in that case you may need to set X1/WAN to DHCP and have it obtain an IP from the modem-router device. If yours is a 2wire brand this may be the case.
I have configured a SonicWALL NSA 240 (the precursor to the 220) behind another router doing NAT and it wasn't a problem, I just had to create rules on both. The only limitation is that the SonicWALL won't allow the same subnet on two interfaces so you can't also use 10.0.0.0/24 for your LAN.
But if I were you I would contact the ISP and ask to either get them to switch it to Bridge Mode (if possible) or exchange it for an actual DSL modem: so the SonicWALL gets the Public IP on the X1/WAN IP (using Static, PPPoE, DHCP, etc). If not you will be limited by the speed/resources/abilities of the combo device which I suspect are not nearly as robust as the NSA 220.
Set user for guaranteed speed of 1Mb and max speed of 2Mb.
This is absolutely possible. Dell has an article outlining this specifically; How To Configure Bandwidth Management with limits Per IP (SW12385).
- Enable
Advanced Bandwidth Management
- Activate bandwidth management on WAN interface and declare the interface speed
- Generate a new bandwidth object and configure it for
Per-IP Bandwidth Management.
- Edit your default
any -> any firewall rule and enable the bandwidth object you created earlier for both ingress and egress.
Also I would like to know if I can set a user for 1Mb of speed with
maximum of 2 GB of download per day then have it reduced automatically
to 256Kb after consuming his 2 GB for the day.
I can't find any documentation that says you can do this, so I would imagine per-ip based bandwidth management is about as close as you can get to evening the playing field for everyone. This is usually sufficient as you wouldn't stand to benefit much from limiting someone who has reached this limit if they aren't effecting anyone else (because you're already guaranteeing bandwidth evenly).
Also I would like to know if I can put such rules on applications
instead of users.
Yes this is certainly possible, but is accomplished in a couple different areas. It's slightly more involved, too, since you setup everything manually versus the per-IP based solution which works across the board. Dell has another write-up for that, as well; UTM: Configuring Bandwidth Management for HTTP Websites using App Rules feature (SW11515).
- Create
Bandwidth object
- Create
Action object
- Match that Action object to the sites you want (or don't want)
- Map the
Bandwidth object to the Action object with an App Rule
Since this is all performed under the Firewall section, it should just begin working across the board.
Good luck!
Best Answer
You have to allow DNS through. Without DNS resolution, the http(s) requests will not finish and trigger the redirect to the login page. What I did was add a rule that permitted DNS for All as the first rule, then everything else permitted for Trusted Users.