Ahh, the latest snapshot won't let you use hyphens, only underscores. That's a good thing :)

Hi,

It was a little bit strange because with the normal 1.2 release I was not able at all and now I can, when I place them in the same vlan ofcourse ;)

I was confused because of the 1.2 BETA1 but with the latest snapshot everything is solved and does work as it normally should.

Thanks !

Matt

Based on recent findings, I would only recommend enabling polling if you're concerned about your management interfaces (console, webGUI, SSH, etc.) being unresponsive while under extreme load ("extreme" varying depending on your hardware). Even cranking up the hz, polling is significantly slower than running without.

@GeeZuZz:

Then i create a new rule, and place it underneath the "Block private networks" rule which is at top.
Block, Protocoll: *, Source: blacklist, Dest.: *,  Port: *, Gateway: *

that sounds to me as if you've added this rule on the LAN-tab.
But rules on your LAN tab wont block connections comming from WAN to servers in your LAN.

thanks for double checking that.  ticket is open.
http://cvstrac.pfsense.org/tktview?tn=1348

Search for log analyzers that understand OpenBSD pf logs, if you're looking for strictly firewall log reporting.

If you want detailed info on network traffic, check out the pfflowd package and look into NetFlow collection and reporting software. There are TONS of options, as this is what Cisco uses on their equipment.

All legit traffic gets passed. Out of state traffic is common and gets dropped. Same as this:
http://doc.m0n0.ch/handbook/faq-legit-traffic-dropped.html

This also drops traffic some hacking tools generate with invalid flags, you'll see a little of that, mostly the above.

Thanks, the Intra-BSS option did the trick..

Damn.. I knew it was something small but I'd never think it hides on this tab :)

Thanks !

Ok!

Thanks!

Josep Pujadas

I still need this ftp-proxy function, any chance only to disable the log ?

Many thanks.

It's possible…need to read up on Squid ACLs. I doubt there is anything in the pfSense gui for Squid that will let you do it though - you'll need to manually edit the Squid config file.

Hi there,

first the good news: the problem really seemes to be gone - at least it did not occur again since updating to the snapshot mentioned in my last post.

However, the reason why that is so, is still in the dark.

I changed since then only two things:

updated the states to 500000 updated the image.

Regarding states, I see even in heaviest times like 1000-2000 states - this is still very, very far away from even the standard 10000.

Again here my setup:

Internet routing x.y.z.w/25 , GW x.y.z.129 –--- x.y.z.130 (WAN-IF)---pfsense (transparent bridge mode)-----x.y.z.135 (LAN_IF)------ clients in the range x.y.z.w/25 via DHCP (without the used ones)

I agree that the blocked traffic looks like out-of-state; however, when the situation occured the GUI showed me much less states than have beeen configured.

Anyway.. for now the problem is solved and i hope it stays like that. If it will re-occur, I'll try to give even more details.

Best regards and keep up the good work!
Arno

It's exactly as Perry points out.  Just remember that the LAN interface can't control traffic starting from the Wireless network or vice-versa.  Nice to see that it's working and that there are no hardware problems either. :)

This actually works with the same subnet on both sides? Is this a bridge, or..?

Totally awesomez!

Thanks, Scott.

stop squid

2)mcserver# nc -l 3128

firefox http://192.168.165.10:3128

netcat returns:

GET / HTTP/1.1
Host: 192.168.165.10:3128
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

firefox http://google.com

netcat returns:

<nothing></nothing>

ok i got an answer:

"…this is a common problem we do encounter with many routers that are not Cisco/AVM,
the address translation of IPSec is not handled correctly, therfore our gateway can't
differentiate between the incomming connections..."

So it's IPSec. Any ideas?

Scott,

It was done.

In fact, I can't reproduce the problem now. Computers …

???

I had FTP Proxy Helper only at OPT4. Now I have it well working at LAN, OPT3 and OPT4 (with localhost rules, of course).

:)

Many thanks,

Josep Pujadas