ughh! i dont understand why we have port forwards AND firewall

[bnelson]

I've asked this question before but I didnt get an answer i was looking for so here goes.

here's what I want to know

Why can't I use the firewall and create a rule that says something like

"any incoming traffic on port 5555, forward to ip: 192.168.1.10"

Instead i have to create a port forward to do it.


or will it work the way i want it to, and i just dont have it setup correctly?

[mdh]

A firewall is a door...its open or its closed. It can't tell you where to go once the door opens...you must chart a course to get to where you want to go...unless you're very fond of walls and bloody noses. Same applies for data.

[sky-knight]

He's gotten used to appliances that obscure this functionality by doing one or the other for you. PFSense is a good example, do the NAT rule and it will create the firewall rule for you.

[datdamnmachine]

Sonicwall's are similar to what he is talking about. The firewall is basically on and you configure all the port forwarding rules in the Firewall menu, I believe. There are a few products that do this as well.

Most high level devices have seperate configuration parameters for both the firewall. Cisco routers, for example, use the "inspect" series of commands to configure the firewall but he "access-list" set of commands to forward the traffic. Most firewalls work be defining internal traffic going outside the network and creating dynamic entries for that specific and ONLY that specific traffic to get back into the network. The key being to "get back". Your firewall is only going to open itself up to legit return traffic and then close that hole. Your port forward is what's going to open a hole in your firewall and keep it open. Hope this wasn't too confusing.

[sky-knight]

Yeah the process of dynamically mapping internal traffic to the wide world and letting it back in is called... NAT. ;)

Of course in a pure world with a consistent IP space and routable addresses on both sides technically that is all part of a stateful inspection firewall.

And as a side note, it is a requirement to keep Sonicwall devices far from my presence... something about me makes them spontaneously self destruct in moments. ;)

[datdamnmachine]

Yeah the process of dynamically mapping internal traffic to the wide world and letting it back in is called... NAT. ;)

Of course in a pure world with a consistent IP space and routable addresses on both sides technically that is all part of a stateful inspection firewall.

And as a side note, it is a requirement to keep Sonicwall devices far from my presence... something about me makes them spontaneously self destruct in moments. ;)

Trust me, it's not you, it's them. When you look up the word "fail" in the IT dictionary, there is a picture of a Sonicwall next to it.

[sky-knight]

Ahh ok, so there are other IT guys out there that have seen that magic "maintenance" light on the Sonicwall mysteriously turn on when they just happen to walk by?

[Ardiem]

I had the same question as bnelson - yes, I'm one of those guys that has only used the combined port-forward firewall rules on the non-professional devices.

So what would you recommend to maintain security but also usablility? A combination of port fowarding and firewall rules or just one or the other? I have an SBS network which requires about 7 ports to be forwarded to the SBS server. I have configured port forwarding to do this so I'm wondering whether I should do anything with the firewall at all. My ADSL router has the same ports open (not forwarded) towards Untangles external IP address which then forwards them to the SBS IP address.

From what has been said, I understand that the port forwarding is like leaving those ports open all the time. How does this affect security and how would setting up firewall rules improve security or affect usability?

[sky-knight]

By default UT has its firewall configured to pass all, but this only changes the firewall in respect to allowing all traffic to and from the internal network. If you have a DMZ, the DMZ network needs explicit firewall rules defined to allow access. Technically speaking you really should have it set to block all and define all your rules but that process is quite a bit more difficult and you need some strong networking skills to effectively troubleshoot why something doesn't work in that environment.

But, to understand how UT goes about all this, you have to realize that we have 3 separate things in play.

1.) NAT (including port forwarding) is done by IPTables
2.) UT's packet filter, is also IPTables
3.) UT's Firewall is some other software that runs inside the UVM

The general difference between the firewall and packet filter is that because the firewall runs inside the UT rack you can have multiple racks with different firewall configurations. Whereas the packet filter is system wide, you have only one to configure.

However, the firewall is only active when the UVM starts up. There is a period of time based on your hardware that the UT server is online, IPTables is up and routing traffic, but the firewall module hasn't loaded because the UVM isn't started yet. During this time period you won't have any protection from the Firewall module and the system "leaks."

As far as security goes any time you "open" a port permanently for connectivity you're technically weakening security. So you forward port 80 to a web server for example, that server is now at the mercy of whomever connects to it. Most of the time it will simply serve up data, but if some nut hits your web service with a some kind of service level attack there is nothing the UT can do to stop it. This is why it is important to constantly audit and monitor your web accessible services to make sure they are up to date with security patches, and correctly configured.

Now, because the UT firewall module lives within the UVM we have some options here to mitigate this risk. If you have the profile manager, you can configure a second rack. This rack would have a different firewall module in it that is set to deny access to your theoretical web server. The policy can be changed dynamically based on the time of day, so you could firewall traffic differently during the off hours. Giving you the option of allowing the web server to function during the day but stopping traffic to it at night.

I have no idea why you would want to have a web server only online part of the time but the option is there.

SBS poses even more issues when presented in this situation.

*Warning*
The author of this post completely despises Microsoft SBS server and has done so since the original NT 3.51 based release. His reasons are varied and he will attempt to keep the venom in the instructive parts of this post to a minimum. :)
*End*

So you have an SBS server, running IIS, and Exchange and a few integrated services between them like OWA...

You have UT at the border and you've forwarded TCP 80, 443, 110, 145, and 25 to the SBS server so that your SBS server can provide to the Internet your Web, Secure Web, Pop3, Imap, and SMTP services.

Now along comes John Q. Hacker, he sees 5 separate services running on your WAN IP address and hits your SBS server with any number of potential service vulnerabilities and owns your SBS server. What have you lost? Exchange? Your web sites?

How about.. your Domain? Your company's files?

SBS made you put everything you hold dear into one server, and you just lost it. Now what? If you can answer that question you've covered your security bases. If you can't...

[seriochka]

To hit your first part of this reply Sky-Night, it sounds as if when using.... NAT (including port forwarding) is done by IPTables, you might also need to define a packet filter for that port you're forwarding, correct?

Our current Watchguard X750 essentially, like others here, combines the Packet Filter, Port-forwarding and NAT into one process that's seamless to the end technology user. I'm wondering if Untangle ...in providing more options for securing your environment...is separating this to provide specificity as to exactly what is and isn't allow in your network.

[dmorris]

Our current Watchguard X750 essentially, like others here, combines the Packet Filter, Port-forwarding and NAT into one process that's seamless to the end technology user. I'm wondering if Untangle ...in providing more options for securing your environment...is separating this to provide specificity as to exactly what is and isn't allow in your network.

Watchguard and Sonicwall boxes are basically evolved firewalls. The started as layer 3 packet filters and have added application layer processing as the market evolves.

Untangle isn't a firewall per say, its a virtual networking platform. Its meant to allow you to build a virtual network in a box so you don't have to keep adding a bunch of expensive appliances. As such, functionality is separated into "modules." The routing, however, is a part of the platform because it was too complicated to users to have them build routing inside the virtual network.

As such, port forwarding, because it determines where packets go - is a part of the platform. Firewall, which is a list of rules determining what is blocked or passed, is implemented as a virtual appliance in the virtual network. As such you gain the ability to do things based on virtual racks, like vary policy by time or AD user. Having a different firewall policy for each AD user is possible and usable, but having a different port forwarding setup by AD user (or time) is confusing and not many uses.

I can understand the frustrations of users who have become familiar with the other way, but its unlikely to change anytime soon because untangle isn't a firewall.

[seriochka]

Watchguard and Sonicwall boxes are basically evolved firewalls. The started as layer 3 packet filters and have added application layer processing as the market evolves.

Untangle isn't a firewall per say, its a virtual networking platform. Its meant to allow you to build a virtual network in a box so you don't have to keep adding a bunch of expensive appliances. As such, functionality is separated into "modules." The routing, however, is a part of the platform because it was too complicated to users to have them build routing inside the virtual network.

As such, port forwarding, because it determines where packets go - is a part of the platform. Firewall, which is a list of rules determining what is blocked or passed, is implemented as a virtual appliance in the virtual network. As such you gain the ability to do things based on virtual racks, like vary policy by time or AD user. Having a different firewall policy for each AD user is possible and usable, but having a different port forwarding setup by AD user (or time) is confusing and not many uses.

I can understand the frustrations of users who have become familiar with the other way, but its unlikely to change anytime soon because untangle isn't a firewall.

I get all of this...and agree with most. I wouldn't expect a product/service to change with my needs all of the time...I think we have to bear some of the responsibility for learning new stuff and how to work with products.

My frustration centers around just knowing exactly which components of what I need to use to get basic functionality working.

[sky-knight]

Basic functionality assumes a small biz network with one of two configurations.

Internet -> UT (router) -> LAN
Internet -> Router -> UT (bridge) -> LAN

Given this configuration and the assumption that in both configuration the untangle server has only two interfaces, and the firewall module is by default in a pass all configuration. The only thing you have to do is configure the port forward rule to enable server functionality. Where this forward rule is configured is different in both of these situations.

The second a DMZ is involved, this assumes a relatively advanced understanding of network technology, and a skill set that goes with it. With that skill set and the documentation provided figuring out if this is a router/nat/packet filter/whatever issue is relatively trivial with UT. Heck, even really wacky and advanced problems are relatively simple to isolate and troubleshoot on this platform.

So if you want the short list of what features of UT are involved with base packet level pushing in regards to port forwarding? The packet will see the Packet Filter first, then the NAT, then the firewall module.

[blizzard182]

Hi Guys!

We just installed UT in our environment. We wanted to manage our own router, VPN and firewall. Another company did this for us in the past but now they are moving away and although I love linux, and don't like to spend too much time playing with consoles and I like what UT gives us.

Now, to the questions.

1) I was looking for something like this. Wondering if you need to set up the firewall and also the port forwarding rule. Well, I just confirmed I do.

I just don't understand something, if the firewall is just a door, why do you have to set a destination address and a port? Does this mean that it will only allow a port forwarding rule to THAT particular port? What happens if I forward the same port to another port in the rule?

Note: You should put something that says where is the forwarding rules. It's kind of hidden.

And 2 more questions:

2) What should I do to enable VPN? I mean, ports and rules.
3) To enable web browsing, do I need any particular rule? Blocking everything blocks internet too, and I don't have the option to allow outgoing traffic.

As you see I am not a well experienced network guy. I just know a couple of things.

Thanks for the help!