Remove the package and then remove dansguardian config from config.xml.
You can do it by editing a backup file or directly with viconfig cmd on console/ssh.

On both cases, be careful.

Hey Aviz,

When using "mode tcp" haproxy cannot modify headers send through the encrypted SSL connection.

You only option when needing to modify https traffic would be to switch to the haproxy-devel package and configure a certificate to perform ssl-offloading/decryption on haproxy, and then modify headers before sending to the backends. You can choose whether or not you want that backend connection to be encrypted again. Which might be required for the application to work properly, though plain http to the backend would take less CPU power. (You might also accomplish this with putting 'stunnel' in front of haproxy 1.4.. But i would not recommend that..)

Another option when using haproxy-devel would be to use its transparent client-ip option. So the backend sees the connection coming in from the actual client-ip.. Please note that backend then 'must' use pfSense as a default-gateway for reply traffic to be properly processed by HAProxy. And that connections directly to the backend will fail with the current 'fwd' rules used in ipfw..

Greets PiBa-NL

@marcelloc:

@rjcrowder:

something definitely got broken in the 2.12.0.3_2 version of the package.

That's the official version from ports compiled by core team, the code doesn't have some patches

@rjcrowder:

At any rate… the workaround seems to be installing the 2.12.0.3 version from your repository...

I'm trying to port e2guardian to freebsd and then pfsense. As I said, dansguardian is no longer being updated by maintainers on sourceforge.
Many commits are pending.

AFAIK, e2guardian will not have use restrictions as dasnguardian has.
The gui will be almost the same, just the package name will change. If core team aproves, it will be applied to pfsense 2.1

Very nice… I'll look forward to that... Thanks again Marcello

Haven't seen that. Any RRD-related errors in the system log?

@marcelloc:

@N3w4dm1n:

For now its not compatible to the last version of pf. Will it be supported next time?

What errors are you getting?

i click start service. nothing happens, i gues i have to check package logs. ill do monday at work!

Thanks, but how about the Open-VM-Tools?

Aren't they supposed to work with pfSense 2.1.2?

Thanks Marcello, I'll have a look at that. :)

@SMuD:

I'd like to install SNORT on my pfSense firewall to monitor packets that get through our WAN interface. I am not interested in the traffic that reaches our WAN but is not allowed in - I want to monitor what makes it inside, after the firewall has parsed the packet.

Does this mean that I should enable snort on the LAN and OPT interfaces rather than the WAN? Since we want to monitor the traffic that is allowed into our network should I enable SNORT on the WAN at all?

Thanks!

Snort puts interfaces it monitors in promiscuous mode, so you are right that it would see and alert on ALL traffic hitting your WAN interface whether the firewall passed the traffic or not.  So putting it on an internal interface is better in my opinion.  This way Snort only inspects what the firewall allowed to pass.  This filters out a bunch of noise.  Another added benefit of having it on the LAN (or other internal interface) is it sees traffic pre-NAT and post-NAT, so you can see the actual internal hosts that may be malware-infected and are attempting to communicate outbound.  Running it only on the WAN means the only local IP you ever see in the logs is the WAN interface IP.  If you don't use NAT, then that is not an issue; but most folks do use NAT and seeing only the WAN IP for all local hosts behind the firewall is not very helpful.

If you run Snort on multiple interfaces, then in the name of memory efficiency and CPU workload, I suggest tailoring the rules for the environment behind Snort.  By that I mean if you don't have mail and web servers on your LAN, then don't run those rule sets on the LAN.  Same idea if you don't have DB servers back there.  You choose the rule sets appropriate for the hosts.  But if you have a monster firewall with a ton of RAM and a beefy CPU, you can certainly load it up with all of the rules on all of the interfaces.

Bill

Hi,

the freeradius motp features is based on a script - modified for pfsense - from http://motp.sourceforge.net/
The script is written for /bin/bash but this is not the default shell for pfsense so you need an additional package "bash".

So there are two possibilities:
1.) Modify the function "function freeradius_motp_resync()" in freeradius.inc starting on line 3897
2.) Rewrite the motp script from /bin/bash to work on the pfsense default shell (recommended)

There is a check on this part - if someone enabled mOTP feature on GUI the the package checks if bash is installed but it only checks on a specific version. If it ist not installed it installs bash. If it is installed and mOTP is still enabled it skips the installation.
If you disabled mOTP bash will be uninstalled.

So bash does not come with the freeradius2 package but it installs later if mOTP is enabled. This is for sure not an elegant solution.

PS: if you download bash manually then you can try to just comment out the lines on feeradius.inc which do the check and installation of bash package.

I see you edited my link from https://www.pfsense.org to https://packages.pfsense.org

It doesn't work with https://packages.pfsense.org, it only works with https://www.pfsense.org.

I just tried it again….

Thanks to keyser, we have try it in our environmet. And HAproxy works for us to.

Editing this page is impirtant for me. firstly i need to edit this file.

@priller:

@priller:

I then went back and tried to reproduce the original problem by removing the IP Blacklist while still having IP REP enable.  Not only could I not reproduce it, but I kept getting 'packets blacklisted' blocks and alerts without having the blacklist selected

Ops, never mind, I was clicking around too fast.  Adding the blacklist to the interface 'sticks' without hitting Save, meaning you can leave the interface configuration and when you come back it is still there. You can be 'tricked' into thinking it is doing something.

Only when you hit Save does it trigger the interface config reload.

Same for when you remove a list.

This behavior could have unintended consequences for the user.  You continue to see a given blacklist applied (or removed), but it is not doing anything. (Got'a protect dummy users from themselves!  :o )

You're right.  Did not think about that.  I will update it so changing a blacklist or whitelist does the restart.

Bill

Hi,

following the steps to reproduce and bypass Snort:

downloaded this script to test the vulnerability (and dump the memory) of the buggy pfsense –> https://gist.githubusercontent.com/sh1n0b1/10100394/raw/4f24ff250124a03ad2d3d6010b6402c3a483d2f3/ssltest.py the attacker runs the script (meanwhile the administrator of the pfsense is logged in from his browser); in the dump file is stored the session ID of the admin's session.
3)at this point, after the dump has occurred, Snort has recognised the attack and blocks the source ip. used a cookie editor (for example cookies manager+ from firefox addons) and create a custom cookie with the session ID extracted before.
5)now if we change the source ip (cell. tethering or using tor if can't change external ip) using the new cookies you will be able to Hijacking the session.

However, for open source projects like this i think we should always see the cup half full( italian proverb :D), it's already so much what Snort does for the cost of 0.

Edoardo

Okay, so I reinstalled the varnish3 package, but I got this error in logs:

php: /pkg_mgr_install.php: The command '/usr/local/etc/rc.d/varnish.sh' returned exit code '2', the output was 'kern.ipc.somaxconn: 16384 -> 16384 kern.maxfiles: 131072 -> 131072 kern.maxfilesperproc: 104856 -> 104856 kern.threads.max_threads_per_proc: 4096 -> 4096 Message from VCC-compiler: Reference to unknown backend 'BACKEND' at ('input' Line 34 Pos 28) .backend = BACKEND; –-------------------------#######- In director specification starting at: ('input' Line 32 Pos 1) director LBD01 round-robin { ########-------------------- Running VCC-compiler failed, exit 1 VCL compilation failed'

I give up this package in my point of view is very alpha.