News: This forum is now permanently frozen.
Pages: [1]
Topic: Check my understanding of a firewall rule with Access Point [SOLVED] [long read]  (Read 3693 times)
« on: March 26, 2007, 10:38:28 »
sundance *
Posts: 5

Hi all,

I have m0n0wall 1.23 running on a PIII. Very, very, very, very happy. Kudos to all who work on the project.

My query is a simple one. I have three interfaces on my box: LAN, WLAN, and WAN.

I recently added WLAN to expriment, so I have a query. But first, the basic configuration.

LAN : 192.168.1.0/24
WAN: (PPPoE)
WLAN: 192.168.2.0/24

On the WLAN (opt) interface, the plan is to essentially add a WAP and have it running on a separate subnet. Even with WPA2-PSK with a 63-character passphrase, I just think it is a good idea to run separately.

Now by default, (once you create a rule on the newly added WLAN interface) no traffic will flow, as per the warning it mentioned. So I kept things simple and created a rule allowing WLAN all access.

I then tightened things, adding a rule blocking access between LAN ---> WLAN and WLAN ---> LAN and moving these rules above the default rule so that it follows the filter heirarchy.

Okay, so far, I hope I'm making sense, as this is my first experience in setting up one of these devices.

Just to expand, I am using a Linksys WRT54G as an access point. Now I know that isn't ideal and I think it is the source of my issue. However, with *nothing* plugged into the WAN of the WRT54G device, and turning DHCP off on the LAN, my understanding is the WRT54G effectively becomes an access point.

So this is what I did. In addition, I changed the IP of the linksys from the default 192.168.1.1/24 to 192.168.2.2/24 (to fall in line with my scheme above). Great so far.

DHCP turned on in m0n0wall, for WLAN interface - all good. Wireless clients associate with the now-modified WRT54G, and obtain an IP from m0n0wall DHCP. All good. Wireless clients are denied access to LAN subnet of m0n0wall, as per the rule, but allowed Internet access. So far so good.

Wireless clients can talk to 192.168.2.2 (WRT54G). Both ping and web access to WRT are good.

So now everything is working well and by my plan, I think. But what if I wanted to configure the WAP from the LAN subnet 192.168.1.0? No problem, I will just disable the block rule and be on my way (I could put an except rule allowing only access from LAN to WLAN IP of 192.168.2.2 (the WAP) but I will get to that later).

So I disable the rule, but no luck talking to 192.168.2.2 from 192.168.1.50 (my IP). Strange, as I thought my configurationw as correct. I tried talking to a wireless client instead... success! I can talk (by talk i mean ping) to 192.168.2.3 and onwards, the clients, without fault.

So this leaves me wondering, and here's my question: is it not my configuration, but rather the WRT54G (remember, running on 192.168.2.0/24 speficially 192.168.2.2), it sees traffic coming from 192.168.1.0/24 specifically 192.168.1.50) and says, nuh-uh! block!?

I really am a beginning, so my sincerest apologies if I have done something wrong or explained something incorrectly.

I realise what I really should have is a WAP and not a WRT54G. However, I am guessing the end result might actually be the same because of the different subnet.

So can anyone see a simple solution to my problem of what I believe is WRT54G denying traffic from separate subnet?


Thank you for your time. Sorry for the long read! I hope I was clear.

sunny.
« Last Edit: March 26, 2007, 18:40:11 by sundance »
« Reply #1 on: March 26, 2007, 14:39:44 »
sundance *
Posts: 5

I have solved the issue, except I will just need to test before I post back.

Looking at it, the answer is so simple (I think... again my knowledge is limited).
« Reply #2 on: March 26, 2007, 18:37:25 »
sundance *
Posts: 5

Okay, after noticing the above pattern, that is, I could ping clients on 192.168.2.0/24 but I couldn't ping 192.168.2.100 or whatever I had the WAP set to, I thought something must be different. Afterall, each device, the client and WAP, both had an IP. Both resided on same network... but what was different?

In short, I think this was the problem. (Excuse my language, it is probably not technically correct or up to the standard of many of the professionals who do this for a living  Cheesy)

My ping and HTTP requests from 192.168.1.0/24 to the WAP were directed and received. However, the packets were originating from 192.168.1.50; on a different network, so how to send response? The WAP needed a gateway to send reply via, otherwise it would do... not much.

I tested my theory by placing a wireless client on 192.168.2.0 without a DNS or gateway... to emulate the WAP sitting there. I installed firewall software and then did the ping test. Sure enough, the packet is received... but no reply is sent back. As soon as I put in a gateway, 192.168.2.1, connectivity is restored.

But how to put gateway into the converted-WRT router?

First led to this page -- http://www.informatione.gmxhome.de/DDWRT/Standard/V23final/index-2.html

DD-WRT software which fortunately ran on my router. I tried it and success, it worked. You will see in the above picture it has the option to set the device's IP, as well as DNS and gateway. The Linksys did not have this option, unfortunately.

I searched around to find out more.. eventually I learned of Static routes... and in fact, the above page, where you have the option to enter a gateway, simply created a static route in the route table. After discovering this, I read up and eventually found I can do this with Linksys firmware.

Despite the appearance of numerous more options and advantages of DD-WRT, I decided that if it died, i would be in trouble, so I decided to go back to Linksys Official firmware.

In the end the solution was simple. Create a static route for all data with destination 192.168.1.0/24 to go via 192.168.2.1 gateway. Voila, and now I can talk to the WAP and configure any settings via wired connection, rather than wireless.

And thanks to m0n0wall, filtering in place to deny traffice between WLAN and LAN interfaces, leads to what I believe a fairly secure setup.

Thanks for reading! I sure did learn something. Hope this might help someone in the future.
« Reply #3 on: April 04, 2007, 10:18:08 »
LifeBoy *
Posts: 13

Thanks for your detailed explanation, Sunny!

Your problem just underlines my point made in a post recently (see "Third interface does not allow ping/traffic?") : We need this static route requirement documented properly in the handbook.  Is it possible to add to the documentation somewhere?  A wiki maybe?
« Reply #4 on: April 05, 2007, 03:13:26 »
cmb *****
Posts: 851

http://wiki.m0n0.ch
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines