The default is keep state on all rules, and you can change it in the GUI if you have a reason to do so. Never manually edit your ruleset, there should never be a need to do so, and it'll just get overwritten anyway.

and disable the antilockout rule on the LAN, on the Advanced page. Make sure you put in rules to allow webGUI access first.

Thanks for the help.  That clears up my issue.

it works

thanks

;D

From memory Windows and Linux traceroute commands use different protocols by default.  Try using the "-I" option with the Linux traceroute to tell it to use ICMP instead of UDP.

@satimis:

Can pfsense run on Solaris?  TIA

pfSense is a product based on top of FreeBSD, not an application.

(In other words, no)

Is there no interest in this topic?

The patch solves some problems with transparent firewalling while at the same time allowing the usage of DHCP for the internal network. What is wrong with that?

Best regards
Arno

They're standard ways of referring to the state of a TCP connection (i.e. not anything to do specifically with pf). This page has a good diagram.
http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html

Don't set your OPT interface to DHCP unless it's connected to an ISP. If it's an internal segment you need to define its IP there. Then configure the DHCP server appropriately.

Your VIP's likely need to be type Proxy ARP or CARP unless they're routed to your WAN IP by your ISP, which isn't typical.

1.0.1 is not recommended for new installs. Try 1.2RC2. Also see http://devwiki.pfsense.org/FTPTroubleShooting

@akoei:

But why LAN computers some time use LAN interface to go out, sometime use OPT1 interface? On another words, if I issue arp -a on a LAN computers, some time the 192.168.5.1 point to LAN MAC address, sometime point to OPT1 MAC address.

Any idea?

It doesn't matter, the firewall answers and works fine with either/or. It's probably a quirk of some sort in the FreeBSD ARP code when combined with if_bridge.

I'm guessing that you removed the 'Block Private Networks' rule.
goto  Interfaces -> WAN.  there is a check box at the bottom of the page to re-enable it.

If you want to block any more connection attempts, take a look at the 'advanced options' button. Matching offenders will get silently dropped via an internal table (virusprot, I think) they remain blocked until the firewall is restarted. The logging is just telling you it did not allow the connection- it does not block future connection attempts from that IP.

We do not have IPV6 support.

All modern firewalls, such as the one pfSense uses, are stateful.  This means you only have to allow the traffic in one direction.

So, leave the default block rule on the WAN alone and create rules on the LAN side allowing outbound traffic (or leave the default pass-all rule alone).  The documentation for pf (the firewall software used in pfSense) can be found http://www.openbsd.org/faq/pf/.

do not post the same question many times - post an example of what you want to do to make things clearer

OK, some progress!  ;)  Since I am bridging LAN to WAN, I created an Advanced, NAT, Outbound Rule like this:
[ LAN    192.168.3.0/24  *  *  *  *  *  NO] where 192.168.3.0.24 is my OPT1 Subnet.  I can now ping from OPT1 to the internet via the GUI.  Now to just get that working on a client machine associated to OPT1.  Thanks in advance.

NickZ

When just clicking save the is no difference in the processor usage. I decided to just disable the "Log packets blocked by the default rule" and the usage normal now. Thanks!