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.

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.