next »

[chipzoller]

I'm trying to better understand forming advanced firewall rules, but this I have not been able to explain or fix.

I have pfsense running after an incoming cable connection. The only 2 clients on my LAN connect into a WAP using WEP encryption. There are no wired clients into this LAN.

I have pfsense running from the liveCD and the current config. was restored from a backup XML file.

The default rule that is created in the firewall lets all traffic from the LAN go elsewhere unrestricted. To play more with this, I changed the rule and went so far as to delete the rule completely (and thus NO LAN rules in place whatsoever) to see if the desired effect would be created. I found in had not and all traffic outbound on the LAN continued to pass to the 'net unrestricted. I even recreated the rule to block all traffic on the LAN outbound (to either LAN or WAN destination) and renewed the firewall states yet no change.

Is there any explanation for this behavior? Have I inadvertently discovered a bug?

many thanks,

CZ

[hoba]

There is one hidden rule that prevents the user from logging himself out from the webgui at lan. You can disable this at system>advanced. Besides that I have not encountered the problem you describe yet with 1.0-RELEASE. What version are you running?

[chipzoller]

I'm running 1.0-RELEASE. I did some further experimenting and cannot explain it. The rule is clearly blocking all traffic out of the LAN yet I (on one of the client machines) can clearly access www fine.

[hoba]

Are you sure this machine is connecting to the worls through the pfSense? Do a tracert from that machine and check if the first hop is the pfSense LAN IP.

[chipzoller]

Are you sure this machine is connecting to the worls through the pfSense?

Sorry, worls? World, perhaps? I don't see how it couldn't otherwise as the LAN structure is simple. Belkin WAP connecting 2 clients which is in turn hard-wired to the LAN interface of the pfsense box (for clarification). The WAP I gave an address way outside the DHCP pool (pool from 192.168.2.2/24-192.168.2.3/24). I don't see how I could have screwed this up, but it's very possible.

Any case it's strange that after a trace route I only get the following for the first 5 entries. And at no point do I see the pfsense box.


1  10.131.0.1 (10.131.0.1)  7.685 ms  5.091 ms  6.008 ms
 2  172.26.96.245 (172.26.96.245)  6.856 ms  6.462 ms  5.750 ms
 3  71-14-0-33.static.gwnt.ga.charter.com (71.14.0.33)  6.010 ms  6.489 ms  8.697 ms
 4  172.26.96.249 (172.26.96.249)  7.895 ms  6.570 ms  8.745 ms
 5  atlnga1wcx1-pos4-0.wcg.net (64.200.231.245)  7.917 ms  8.297 ms  7.942 ms

[hoba]

Any chance you are connected to a neighbors network? 

[chipzoller]

Damn myself....apologies. I stupidly did a traceroute without thinking from the pfsense box and not the LAN client.  Yes, a trace route from the LAN client shows the first hop to be the pfsense box followed by entries 1-5 in my previous post.

[hoba]

Did you try to reboot the pfSense?

[chipzoller]

I actually did a complete restore to defaults just yesterday with no change, however I'll try another reboot of pfsense and see if it changes anything.

[EDIT] Ok it looked like after that last reboot the rules started being obeyed. Not only that, but after the reboot I could then change the rule from block to pass, apply the rule, refresh the states and the newly edited rule was being obeyed. I don't know why I had to do all that to get firewall rules to be active, but it works now. I hope this hasn't been a waste of your time, hoba.

Thanks for the help here.

[sullrich]

This is a known bug and has been fixed.   Search the forum for check_reload_status.

[chipzoller]

Ah, ok I thought it might be. How do I go about applying the fix for this? I'm not familiar with the inner workings and files associated with pfsense as of yet. Any newbie explanation would be most appreciated.

thanks

[hoba]

It will be included in the upcoming 1.0.1 release. If all goes well it will be released around this weekend.

[chipzoller]

I'm not sure if this is related at all, but I thought I might mention it here before starting a new thread.

Apparently, when changing the webGUI port from default to custom, it is also necessary to reboot the system before the changes actually take effect. But according to the description below the webGUI port field, "Changes will take effect immediately after save." I found this not to be the case. Only when I rebooted the system did the firewall listen on the new port.

[hoba]

Should be related.