packet filter rules for wireless dmz

You have to allow PPTP (port 1723) traffic from the DMZ network. That gets the the PPTP traffic from the Wireless laptops, through the Access Point, into the ASL box. If you are pointing the tunnel clients using an IP address, then that's all you need. If the wireless clients points to the tunnel using a URL, or if your Access Point hands out DNS server addresses to its wireless DHCP clients (as is commonly done), then you should also  open port 53 for DNS.

The PPTP tunnel is automatically routed through to the Internal network by ASL, so you don't really have to do anything there.

However, if you want to let the tunnel clients access the Internet, you should create a 2nd masquerading rule, similar to the one you have for masquerading the Internal network behind the External interface, except now you are masquerading the PPTP-POOL behind the External interface.

I have had my Wi-Fi  router working on my DMZ network for a few months now. I run a PPTP tunnel inside the WEP connection, and then I run Microsoft Remote Desktop inside the tunnel. That's three 128 bit encrypted circuits inside of each other, but my old P-233 laptop handles it fine.

how about using ipsec instaed of pptp?

what rules do have to apply?
i'm running a wlan on an seperate interface and assign virtual ip's from my internal network once the ipsec-connection is established.
there are no probs when doing this using pptp...
the client gets its virtual ip and is able to do everything, clients from the internal  are allowd to do (e.g. access the internet...).
the problem shows up when using ipsec:
the ipsec-sa ist established and the client gets its virtual ip from the internal subnet...
but i'm unable to connect to the internet or even ping a client from the internal network :-(

any ideas?

thx in advance...

GoFast

I have no good ideas on your IPsec problem. You are getting ahead of me. I have never used IPsec from client PCs, just PPTP. I did try an IPsec client once, but ended up having the same problem you described, getting my Internet access got cut off.

However, to run IPsec, you do have to open up port 50, port 500, and perhaps also port 4500 in your packet filter rules.

roger that...

the prob is not the ipsec-connection to the asl-box...
this works fine and the client (i'm using ssh-sentinel + x509certs) accuires the predefined virtual ip (one from the internal-network-subnet)...
strange enough... why can't i even ping a host inside my internal network while having an ip-address of this subnet??? :-(
do i have to configure something else beside the vpn-connection inside the ssh-sentinel-client (secured networks???)?
if doing the same thing while using pptp, everything works fine...
seems like i gotta work on this one ;-)

any ideas appreciated...

GoFast...

The only essential requirement to get the routing of packets to work, is that the net numbers  (the bits you get when you do a logical AND between an IP address and its netmask) on the routed network segments are different. If they are not, then the router has nothing to work with, and it won't be passing the traffic.

The only essential requirement to get the routing of packets to work, is that the net numbers  (the bits you get when you do a logical AND between an IP address and its netmask) on the routed network segments are different. If they are not, then the router has nothing to work with, and it won't be passing the traffic.

Make a packet filter allowing traffic from the ipsec key to the internal network. Also make a packet filter allowing traffic the other way around.

hi...

thnx 4 the hint...
after changing the "virtual-ip (assigned when the ipsec-connection is established)" from one out of the "internal network" to one out of a completly new pool and adding filter rules to allow inbound and outbound traffic between the "ipsec-net" and the "internal network", i'm able to communicate between the two nets (ipsec  internal network).
the mess is, my internet access from the "ipsec-net" is cut of.
i'm normally using nat/masq to access the internet from the "internal network" (which still works fine ;-)).
adding an second nat/masq rule that masqs the ipsec net changed nothing...still no i-net access from the ipsec-net.
any ideas???

thnx in advance...

GoFast

sorry folks...

it was my own fault...
i had an error in my ssh-sentinel-config:
the remote-network was set to the internal-network, instead of using  any.
this setting made ssh-sentinel drop all packets, that where not targeted to my internal lan.
after setting this to any (and applying the appropriate setting to the ipsec-connection on the asl-box), i'm now able to connect to both, internal lan + internet via internal lan (with no split tunneling).
so all traffic is encrypted (an ethereal-analysis showed this) and i'm happy ;-)

GoFast

velvet frogcan you give me more details about your wireless dmz setup. I'm still trying to get mine up and running. First of all I would like to ask did you define your ap as a host than again I don't know if that matters? Secondly I would like to ask are you using the standard pptp pool that begins with the 10.229.199.0 range?  I'm going to tell you waht rules I've created so far I have a rule that allows dns traffic from the dmz to flow into the internal network. I tested it and it works. When you say you have to allow port 1723 traffice from the dmz network  are you saying that this traffic should be allowed intot he internal network?  That may sound stupid but I'm trying to figure out why my setup is not working. I created a rule to allow pptp traffic from the dmz into the internal network. After that rule was created I established my vpn session I than went back and tried to ping servers on my internal lan but it did not work. So I created a rule to allow dns access from the pptp pool to the internal network and it started working again.

[ QUOTE ]
velvet frogcan you give me more details about your wireless dmz setup.

[/ QUOTE ]So I'm a frog now. My handle is VELVETFOG.

[ QUOTE ]
First of all I would like to ask did you define your ap as a host than again I don't know if that matters?

[/ QUOTE ]I use a wireless router as my access point. The WAN connection on this router is connected to my DMZ.

[ QUOTE ]
Secondly I would like to ask are you using the standard pptp pool that begins with the 10.229.199.0 range?

[/ QUOTE ]There is no standard PPTP-POOL adress range. It is 10. something subnet with an address picked by a random number generator when you install ASL. Mine is the 10.244.243.0 net. But yes, I am using the default PPTP-POOL address range that ASL gives me.

[ QUOTE ]
I'm going to tell you waht rules I've created so far I have a rule that allows dns traffic from the dmz to flow into the internal network. I tested it and it works.

[/ QUOTE ]You don't want the traffic from the DMZ to be able to access any machines on the Internal network. The whole idea of a DMZ, is not to allow access from there to the Internal net.

[ QUOTE ]
 When you say you have to allow port 1723 traffice from the dmz network  are you saying that this traffic should be allowed intot he internal network?

[/ QUOTE ]The port 1723 (PPTP) and the port 47 (GRE) traffic from the DMZ has to be able to get to the ASL box without being dropped at the interface. From there, it is the traffic that runs inside the PPTP tunnel that enters the Internal network.

[ QUOTE ]
That may sound stupid but I'm trying to figure out why my setup is not working. I created a rule to allow pptp traffic from the dmz into the internal network. After that rule was created I established my vpn session I than went back and tried to ping servers on my internal lan but it did not work. So I created a rule to allow dns access from the pptp pool to the internal network and it started working again. 

[/ QUOTE ]Maybe you should publish the packet filter rules that you have created so far, and let us look at them. Personally, I do my packet filter rules using defined groups, and my rules look like this:

Any  Any  Broadcast32   Drop
{ Local_LANs }  { Drop } Internal_Interface__  Drop 
{ Local_LANs }  { Drop } Internal_Broadcast__  Drop 
DMZ_Network__ { Drop }  DMZ_Interface__   Drop 
DMZ_Network__  { Drop } DMZ_Broadcast__  Drop 
{ Local_LANs }  Any  Any  Allow 
DMZ_Network__  { DMZ-Services } Any  Allow
DMZ_Network__  Any  { Local_LANs }  Drop 
Any  { Local-Services }  Any  Allow

Note the order of the various Drop and Allow rules.
As you can see, these filters depend on three service groups:

Drop This group contains all the Microsoft Netbios stuff
DMZ-Services This group contains all the services I am willing to permit on my DMZ network, such as DNS,  PPTP, NTP, etc.
Local-Services This group contains the services that I always want to allow through.

I also use one network group, since I have additional subnets inside of my Internal network:

Local_LANs  This group includes all my permitted local networks,  including the PPTP-POOL, but NOT the DMZ network.

This setup has worked well for me on ASL v4. I don't have to change my filter rules any more, I just add or subtract services in the groups that I have created. The first five rules simply drops stuff that would otherwise be log dropped by ASL. This keeps the size of the daily filter and kernel logs down to a manageable level.

VelvetFog  check your email I sent you a word doc containing some of the rules I'm trying now. I did'nt know if you were coming back to this thread thats why I sent it out.

I got your email. and looked at the picture in the attached word doc.

None of the rules you have created actually do anything.
On a working PPTP tunnel, all types of packets travelling inside it, will get routed to the Internal network, so the PPTP - Netbios rules you created are all unnessessary, you can delete all of them. Having a separate rule to allow HTTP access out from the Internal network, is also quite pointless. You may as well allow ALL traffic out from the Internal network, why restrict yourself to just HTTP? What about DNS, FTP, IRC, NTP, PPTP? Don't you need these other protocols working for you as well?

Going from the Internal network out to the Internet, there is no point in blind siding yourself. You don't implement network security by preventing yourself from seeing out to the Internet. You do it by carefully controlling how others can get to see in to your network. You really ought to put in a basic access rule to give your Internal network free access to the outside, such as this:

Internal_Network_  Any Any Allow


Here are the group definitions for the three groups I used in my packet filters:

DMZ-Services
{ ping }
{ traceroute }
DNS
DNS-Reply
FTP
HTTP
HTTPS
IMAP
NTP
NTP-Async
POP3
PPTP
SMTP
SQUID
SQUID-Reply
SSH
SYSLOG
TIME
WHOIS  

Drop
{ Microsoft-SQL }
{ netbios }
Microsoft-SMB
uPNP
 
Local-Services
{ ping }
{ traceroute }
BT-6881
BT-6969
DNS
DNS-Reply
FTP
HTTP
HTTPS
IMAP
MS-RDC
NEWS
NTP
NTP-Async
POP3
PPTP
SMTP
SNMP
SNMP-LOG
SQUID
SQUID-Reply
SSH
SYSLOG
Telnet
TIME
USERMIN
WEBMIN
WHOIS

Note that a number of the definitions in the lists above are custom definitions that I have created myself, so you won't find WEBMIN and USERMIN, as an example, in the definitions that comes with ASL. They are for opening up port 10,000 and port 20,000 for WebMin access to a RedHat Fedora Linux server on my Internal network.

As you can see from the above group definitions, if I tried to make individual packet filter rules for each of these items, instead of using groups, I would end up with an enormous list of packet filters, and it would be insane trying to manage it all, since the three groups total more than 50 service entries, some of which are themselves groups.

Keep in mind that when you are creating filters using the ASL Webadmin interface, what you are really doing is creating entries into the Linux IPtables routing code. In  IPtables, an entry in a table can be a pointer to yet another table. That is why you can put protocols into a group, put that group into another group, etc., and in the end, use a group in your filter definitions. This is powerfull stuff, allowing for a great deal of nested complexity.

You need to get away from thinking in terms of simple packet filters, and instead consider what packet traffic you wish to allow, and from where, and what you wish to drop. Then you use groups as your categories, use the groups in a small number of carefully defined  filter definitions, and then you can just dump the entries you need into the various groups. Not counting the five drop filters that I use to keep the log dropped junk out of the filter and kernel logs, I use just four filter rules, three group definitions and one network group definition to achieve a relatively complex filtering system on my ASL box.

The most important thing for you to get your PPTP working, is to allow the PPTP traffic from anywhere to anywhere. Then that problem is solved. And if you study my rules and group derfinitions, you'll see that the PPTP traffic is allowed everywhere, in any direction, from any Interface.

A simple rule such as:

Any PPTP Any Allow

will be enough to give you PPTP access from your DMZ.

Ok its obvious I need more help on this firewall stuff. Is there any books or websites that you can recommend that talks about building dmzs. I think I understand your use of groups basically you'll take all services that you want to allow into your internal network and put them in a group. Instead of what I was doing which was adding services one by one and giving that service access to where ever I wanted it to go. I now understand that nothing from the dmz is to ever touch the internal network, but of course I can allow services to function within the dmz for example a web server needing http or a mail server needing smtp.  So I will use your approach when it comes to groups. I'm going to try to take this step by step. I'm going to design a group of services that I want to have internal network access,  a group of services that I only want to have dmz access. I hope this is at least a start to getting this working.

Also keep in mind that you end up with three local networks that all probably should have access to the Internet, the Internal network, the DMZ and the PPTP-POOL. You therefore need three masquerading NAT rules, masquerading each of them against the External interface. If you have already created a masquerade rule for the Internal interface, the other two are easy to set up, since they are similar.

I don't know of any books specifically on the subject of firewalling for a DMZ. But the basic principle is very simple, you make an inventory of the services you wish to allow, and which ones you wish to block, and create your rules accordingly.

If all you have on the DMZ are a few servers, such as web and FTP, it is all very simple. Then you just have to open a few ports for them. My setup has the added complexity of me having my wireless access pint on the DMZ, and I wanted sufficient capabilities on my DMZ network for basic things like DNS service from my own DNS server (which is on my Internal network), and general Internet access, to work over my Wi-Fi connection, even when I didn't open up a PPTP tunnel to my Internal network. I have two laptops with Wi-Fi cards in them that I use around the house, so this was important to me.