Squid should have all of that in its access log, I believe. EDIT: Not sure about the file name on second thought. That might depend on the upload form. It should at least show a POST request, who did it, when, and where though.

Check your port forwards and make sure their "external address" is set to your WAN address, and not "Any". That can cause problems if you have NAT reflection enabled, and will do almost exactly what you describe.

Point taken… I am noticing that FTP seems to be able to get out without an enable rule, I can create a rule to block it though. Any other ports that PFSENSE will have open by default?

Thanks for the replies. I did find a solution. I disabled the FTP Proxy on the LAN tab. I am unsure why but everything immediately started working. I then went in and modified the rules to allow only the vendors subnet instead of the entire world. I appreciate the help.

I doubt you will see a modified approach to work exactly as you describe. By default all new interfaces (other than the default LAN with its default allow any rule) block all traffic. Then you allow only the traffic out that you want, in your case possibility2 works very well to accomplish what your goal is. Aliases provide an easy way to get this functionality. pfSense generally requires that you understand how firewall rules are evaluated once you move beyond a basic LAN/WAN two interface setup, in order to configure things properly, but it's very powerful (and secure-by-default–except for the default LAN-out rule which is less secure but expected behavior) once you understand how rules are evaluated. And it's actually kind of nice IMHO to have all interfaces be on "equal footing" with each other, without special rules unless you create them (although LAN and WAN are a bit different, but still you can have multiple of either, with a WAN being defined as having a default gateway and any other interface is internal, and there is more "automation" to NAT rules than direct firewall rules). In other words, you need to understand how pfSense does things (which is more like many enterprise firewalls and routers than home ones) to configure it well. I don't see that changing, though 2.0 does add a lot of nice new functionality. But conceptually very similar. However, in version 2.0 (still in beta though usable to some extent, arguably (sometimes heavily argued :-) ), you can create "interface groups." Add whatever interfaces you want to a group, and then create rules that apply to all the interfaces in that group. The rules still apply after the direct per-interface rules (as far as order evaluated) but it may give you a more logical layout to accomplish what you're wanting to do. You'd still need the LOCAL alias, as pfSense does not have a built-in idea of "all protected networks" beyond "this is a WAN" and "this is a LAN" (as defined as having a default gateway or not). It makes more sense this way too, given that many people have multiple WAN connections and multiple LAN/DMZ connections; assumptions would likely only work for some cases. There's my six cents ;-)

Can you post /tmp/rules.debug?

You cannot use synproxy with a bridge. A recent discussion on the freebsd-pf mailing list describes why, pull up its archives for a thorough explanation. SYN flooding isn't of a whole lot of concern anymore unless you're running 10+ year old OSes behind your firewall, pretty much every modern OS handles SYN flooding on its own very well. As for DDoS protection in general, you have a 100 Mb pipe, which means even a small DDoS is going to take you completely offline by overloading your connection to your provider. There is nothing you can do to change that, it's too late once it gets to you, and you can't do anything about the traffic upstream. Your provider would have to help in such scenarios.

The default deny rule is hard coded and cannot be removed, anything that doesn't match a user-defined rule hits it. Short of modifying the source code to take it out, you cannot disable it. You can override it with user-defined rules, essentially eliminating its purpose if you allow everything on every interface.

Assuming you mean in the pull-down menu for the port? SIP is udp/5060, although some providers (few now, AFAIK) support SIP over TCP.

DOH! Bypass firewall rules for traffic on the same interface  … check this box.. all is good

good to hear.

Thanx for the hint, it does seem it did the trick, the logging is working again. There are a few tabs where logs are not yet updating, like OpenVPN, thought something should've been noted there in 3 hours. I'll keep an eye on it, FW logs are working though, I can do test connections and see that they are entered in FW log vindow. Right now I have a somewhat "complex" setup with a VPN as a second WAN interface and doing some route adding and deleting manually and using that with policy routing, but this shouldn't have anything to do with logging working or not I guess?

Then disable or remove that rule.

Thanks for the reply. I had a hard time defining my question but you answered it. I came up with the question because I had read somewhere that when you add one extra LAN (OPT1) you need to check destination "not LAN subnet" for incoming traffic. The person who wrote that article may have been mistaken. I think they were under the impression that packets might accidentally flow into the other subnets. I suspected that PfSense routed traffic appropriately to the right internal IP/port but wanted to be prepared for a routing problem in case the network went down. Now i can sleep properly.  :P

How do you have WAN/LAN setup exactly? (screenshots may help) In a transparent scenario, WAN should have an IP in the subnet you want. LAN should not have an IP in that subnet, and it should be set as a bridge to WAN.

Oh crap, I forgot to mention that I did try the DenyHosts package however it never seemed to work on my setup.  There were several instances of ssh login attempts while the package was running and it never did anything. But your suggestion of using a certificate is a good one.  I've thought about giving it a try, maybe I just need to take the plunge and do it.

In 2.0 you might be able to do this with Interface Groups, but in 1.2.3 you just have to duplicate rules. You could probably generalize them a little with proper use of aliases.

Two options: Use a TFTP server that follows normal networking rules, i.e. replies with the original source and dest ports flipped. Use 2.0 with the TFTP proxy.

You either need the ports, or the IP block, that the game will use. You can find the former with Google, most games will give you that info. The latter can be found via Google likely as well, or search ARIN for one of the provider's IPs, which should give you their full block (if it strictly goes to one IP block that will work).

http://forum.pfsense.org/index.php/topic,26671.0.html