Making the DMZ a Internal Network (192.168.2.x)

[marley1]

Hey guys, I just grabbed a 1u Rackmount to mess around a little with Untangle.

What I had before was a Freedom9 Firewall that had a DMZ port working as a 192.168.2.x network which served our client machines. The LanPort 0 was our 192.168.1.x network that servers our internal network.

The 192.168.2.x side had a NAS which served DHCP to the client machines and also had our FTP Server

The 192.168.2.x side couldn't see the 192.168.1.x side, but the 192.168.1.x side could access the NAS (192.168.2.10).

I set up the DMZ port to be Static with 192.168.2.1/24
In Packet Filters I enabled Accept DNS traffic to the local DNS server from all interfaces.

So on the 192.168.2.x side I can now browse online.

But I can still ping units on the 192.168.1.x side.

What is the correct way I want to start that out.

se

[sky-knight]

Sounds like you've got it setup correctly.

A few things to keep in mind.

1.) the rack only processes TCP and UDP traffic, so if you use the firewall module to control access, you will always be able to ping across the segments.
2.) The advanced section has a "nat only wan traffic" option that can be used to force all local segments to be NAT'd to the internet to solve the former, but it also kills all access between the two segments that isn't done with a port forward.
3.) The packet filter can be used to control just about anything but it doesn't have a log.
4.) the DMZ interface won't get pretty block pages from the web filter and other modules.
5.) Accepting DNS on all interfaces includes external, you may want to fix that.

[marley1]

don't care about the block pages on teh 2.x side.

just want to only give the machines access to the internet and the NAS
want to block them from sending mail
want to be able to access the FTP server from outside.

could you give me a little step by step?

in the old firewall we had the 2.x dmz port handling the dhcp server, is it possible to have a DHCP and DNS server on Untangle just for the 2.x side?

[sky-knight]

Look in the packet filter rules for DHCP and you will fine some interesting options that make your DHCP wish come true.

DNS is simply a matter of enabling access to UDP port 53 destined local, custom packet filter rules to do this are relatively trivial to create as well.

As for the general blocks, you more than likely will need to enforce things, so create a block rule that simply blocks and logs anything from 2.x destined to 1.x and then create pass rules above it to pinhole the services through you want.

I could give you the hand holding approach, but you really need to know what the Untangle is doing in this type of configuration or troubleshooting will bite you in the arse later.

The wiki is your friend, if you have more specific questions the forums are a good place for clarification.

http://wiki.untangle.com

[DrumScum]

Originally Posted by sky-knight

2.) The advanced section has a "nat only wan traffic" option that can be used to force all local segments to be NAT'd to the internet to solve the former, but it also kills all access between the two segments that isn't done with a port forward.

So in orde to have access from a static DMZ interface (without NAT) to the static 'Internal' interface (with NAT) is to enable NAT on the DMZ? Or is there a way to circumvent this?

[sky-knight]

Well no NAT policy on the DMZ interface + and internal IP space means no internet on that segment at all...

But if you need the two segments to communicate directly, you have to turn off that nat all packets box, and then create packet filter rules to allow traffic to pass. I don't have all the specifics on this process, I just "do it" when I need to and don't think much about it anymore.

But, be ready to get good at creating packet filter rules, and I suggest you read up on how to use TCPdump, you're going to need it.

[DrumScum]

Originally Posted by sky-knight

Well no NAT policy on the DMZ interface + and internal IP space means no internet on that segment at all...

I've a /28 netblock at my disposal, so I have plenty of public addresses to play with.

Originally Posted by sky-knight

But if you need the two segments to communicate directly, you have to turn off that nat all packets box, and then create packet filter rules to allow traffic to pass. I don't have all the specifics on this process, I just "do it" when I need to and don't think much about it anymore.

You mean the packet filter in Config > Networking > Advanced then? Right, I was already thinking in that direction. I am a bit confused though by having packet filtering *and* a "firewall". I am used to do this in one go with pf.

Originally Posted by sky-knight

But, be ready to get good at creating packet filter rules, and I suggest you read up on how to use TCPdump, you're going to need it.

tcpdump is a good tool, but I don't use it that much really. Usually ping, telnet and netcat are able to tell me what I need to know.

Thanks for the suggestions.

[sky-knight]

Ahh a fellow PF addict, yes you'll get this figured out soon. I came from the same background when I found Untangle.

Just some food for thought that will help you out here.

1.) No interface save internal has ANY NAT policy by default. This means that for your DMZ adapter, or any other adapters for that matter, when you want them to be "internal" you need to go put a NAT policy on that adapter so IPTables is configured to NAT traffic landing on that interface. You don't need multiple Internet IPs for this, you just need to get something in there.

0.0.0.0/0 auto is the default policy, I usually slim mine down to match the segment on the adapter. EG, if the DMZ adapter was running 192.168.2.1/24, my nat policy for that lan would be 192.168.2.0/24 auto.

Finally, the Firewall vs the Packet Filter...

The Firewall lives inside the rack. The Packet Filter lives in the linux kernel. They operate and think in very different ways.

First of all the UVM (Untangle Virtual Machine) that runs in that huge java process you see in the background is where all your virtual racks live. Assuming you have the policy manager you can create as many racks as you have resources for... Each rack is essentially its own security context, then using policies you can pick and choose what packets go into what rack. Allowing you to dynamically change the security context impacting any given packet based on the criteria set in the policy manager. That is dime of day, source address, destination address, source port, destination port, etc. If you own the AD connector you can even move packets around based on the AD user name.

The firewall module is part of that process, it is in a rack. So you can have firewall rules that impact some users, but not others. It is an incredibly flexible framework.

However, you have to keep in mind, due to performance reasons, the UVM only processes TCP and UDP traffic. So the firewall module can only see TCP and UDP traffic.

So what is the packet filter?

The packet filter is even more simple to understand. It's Untangle's GUI for configuring IPTables within the linux kernel. This firewall can deal with all protocols, and it is also the only way to control access to the Untangle server itself.

By default IPTables is block all, so when you get outside the normal defaulted configurations of the Internal adapter you have to make some changes to get traffic to flow.

TCPDump is vital to making that determination, with multiple SSH shells you can have it running on two interfaces of Untangle and see exactly where the traffic is failing, and know what module to kick.

So the short answer, use the firewall module to control traffic passing THROUGH the Untangle server.

Use the Packet filter to control packets destined TO the untangle server.

However, there are times when the packet filter rules are needed to get cross interface traffic moving. Also, there is no easy to read log for IPTables events... to anytime you need enforcement keep the rules in the Firewall Module.

And, the classic warning, The packet filter is advanced for a reason, be careful in there, you can lock yourself out of even the local console administration with the wrong rule.

[DrumScum]

Thanks for your thorough breakdown. It cleared up a few things for me.

In the meantime I got traffic flowing from my NATless DMZ to my NAT'ed internal by adding one simple rule to the packet filter. Great stuff.

For those interested, this is the rule:

* Pass
* Source address: DMZ network (e.g. 172.16.0.0/24)
* Destination address: internal network (e.g. 10.11.12.1/24)

I now can start finetuning this, because obviously I don't want all of my DMZ to see all of my internal network.

[sky-knight]

Use the packet filter to get packets to flow, then use the firewall module to lock down TCP and UDP traffic specifically. Then you'll get nice reports on the problems every night.