Observations : comments invited.
-
These are a few of the 'annoyances' that I have encountered whilst using V2, I have temporarily rolled back to V1.2.3.
1 : IPSEC - Doesn't work as it should, IPSEC flatly refused to work in pfSense 2 and yet works fine in V1.2.3 with identical settings, there are many reports on this forum about VPN issues, I am sure they are related and yet the 'bug list' seems to indicate no issue with IPSEC … well I think there is whether developers accept it or not.
2 : An issue that I have had with Snort updates when using the latest V1.35 snort seems related to browser version because the updates still fail even in V1.2.3 - rules can not be updated unless you run Firefox/Mozilla - this is not acceptable, packages must support ALL browsers and be produced using W3C standards NOT browser specific standards. I don't care how sexy that pop up looks if only one browser supports it then don't use it! maintaining a truly universal standard is as important to the internet as the survival of open source and GNU licensing, how many of those producing packages that work only in Firefox slag Microsoft for restrictive practices I wonder.
3 : Cron updates of Snort rules also don't seem to work. I also checked the php associated with the updates and was disappointed to find 'version numbers' hard coded in there - rule 1 transient values MUST be parameters. When the php is executed this still reports a bunch of 'missing folders' - folders that should have been (or are assumed to have been) created by a tar extract so I am not sure that this method works. Snort package 1.35 doesn't correctly display the snort.org installed rules anyway whether the install is manual or via Firefox/Mozilla.
4 : Cron lacks the ability to configure e-mail notifications without going into the console, it still tries to send E-Mail alerts though - not very well thought out. A much better GUI is needed for Cron, the settings for Cron are not intuitive either, the GUI needs to simplify the process !!
5 : apinger - this app is a nuisance, it misreports faults especially on busy connections (it is pre-occupied with its own agenda like many IT departments), even if those connections are not overly busy in bandwidth terms but apinger hates burst traffic. Apinger also causes excess ICMP type traffic, ignores settings designed to control it even if put in apinger.conf directly (and this is the ONLY way to modify the ping rate - see apinger.conf line Interval =) as changes in the pfSense console are not reflected at this location. No internet connection is important enough to warrant sub minute poll rates, if you think it is then you need to take a seriously hard look at your architecture, pfSense is a firewall NOT a router/managed switch. There is also still a BUG notice on the apinger source about high load http://apinger.jajcus.net/trac/browser/trunk/BUGS
6 : apinger is totally unnecessary for anyone who has only a single ISP connection and yet it can not be disabled without accessing the console and killing its process. ISP's are not going to tolerate 100s of users ICMP'ing their routers / gateways every 1s !!! - I wouldn't even tolerate it internally from users.
7 : Clearing states automatically because apinger reports a fault is also not acceptable, this needs to be an option (I note that is is on the to do list though)
8 : FTP - flat out couldn't make this work reliably, one day it would and the next not, reboot pfSense and all would be fine again for a while, could find no reason for this whatsoever .... works fine in V1.2.3
9 : I'd like to see the pfSense install separated from the specific FreeBSD OS, treat it more like an application than a bundle - again there is much hardcoding in some php related to the OS version ... this kind of thing makes maintenance very difficult especially when security fixes for embedded stuff like php are released.
I am happy to roll V2 out again but only if somebody wants to work through one or more of the above items.
-
1 : IPSEC - Doesn't work as it should, IPSEC flatly refused to work in pfSense 2 and yet works fine in V1.2.3 with identical settings, there are many reports on this forum about VPN issues, I am sure they are related and yet the 'bug list' seems to indicate no issue with IPSEC … well I think there is whether developers accept it or not.
I'm only aware of some DPD issues with IPsec where a tunnel won't reconnect after a peer loses connectivity. I haven't heard of any other issues. We would need a complete description of the non-working setup, preferably with a copy of the config or screenshots of the GUI settings used. The IPsec GUI was completely reworked in 2.0 so if you configured it by hand from scratch (not an upgraded config) then it's possible someone may think it was done the same but it wasn't quite right. The contents of the IPsec logs on both ends would be needed also.
2/3 [snort items]
Agreed about the browser issue. If you start a new thread with snort in the title, the snort maintainer (jamesdean) should see it and take it under advisement. He probably wouldn't find this thread (I'm not sure how closely he follows the forums).
4 : Cron lacks the ability to configure e-mail notifications without going into the console, it still tries to send E-Mail alerts though - not very well thought out. A much better GUI is needed for Cron, the settings for Cron are not intuitive either, the GUI needs to simplify the process !!
What modification did you make at the console to make it work?
The PHP mailer we have setup doesn't replace sendmail, which is how cron normally sends out notifications. It's not that it isn't well thought out, it isn't expected to work. The GUI for e-mail notifications is for pfSense notifications, not OS e-mail alerts. There isn't any reason why those can't eventually be made to work, though, it just isn't how it was intended to work (yet).
5 : apinger - this app is a nuisance, it misreports faults especially on busy connections (it is pre-occupied with its own agenda like many IT departments), even if those connections are not overly busy in bandwidth terms but apinger hates burst traffic. Apinger also causes excess ICMP type traffic, ignores settings designed to control it even if put in apinger.conf directly (and this is the ONLY way to modify the ping rate - see apinger.conf line Interval =) as changes in the pfSense console are not reflected at this location. No internet connection is important enough to warrant sub minute poll rates, if you think it is then you need to take a seriously hard look at your architecture, pfSense is a firewall NOT a router/managed switch. There is also still a BUG notice on the apinger source about high load http://apinger.jajcus.net/trac/browser/trunk/BUGS
You can, in the gateway settings, tweak the loss/delay that triggers alarms. A field to tweak the interval would be nice to have there as well. Ermal is writing a new program to replace apinger, so many of these items will be moot points by release time. Many would disagree about sub-minute poll rates, and I'm one of them. For some, 1s may be far too often, but 1m is far, far too slow. If it were configurable, everyone could be satisfied.
6 : apinger is totally unnecessary for anyone who has only a single ISP connection and yet it can not be disabled without accessing the console and killing its process. ISP's are not going to tolerate 100s of users ICMP'ing their routers / gateways every 1s !!! - I wouldn't even tolerate it internally from users.
I thought there was a ticket for that, to give the ability to disable the checks if you only have one WAN. I would still find the quality graph data collected by apinger useful even if I did not want the alerts/actions to happen, so ideally there would really be multiple modes - on full, graph only, and completely off.
7 : Clearing states automatically because apinger reports a fault is also not acceptable, this needs to be an option (I note that is is on the to do list though)
Agreed, the option would be nice for single WANs, though on multi-WAN environments it is useful - but only when the WAN has actually completely failed. I believe that tweaking the detection for a given WAN would minimize the impact of this overall, but that would depend on a given WAN - for example my Cable line is fast and works fine, though some loss is reported. So I had to tweak the acceptable "loss" so that apinger wasn't as aggressive about killing it. My DSL line tends toward high latency so I had to do similar tweaks there.
8 : FTP - flat out couldn't make this work reliably, one day it would and the next not, reboot pfSense and all would be fine again for a while, could find no reason for this whatsoever …. works fine in V1.2.3
This was problematic for me in September snaps, but I haven't had any issues since the Oct 2 snapshot or so. I don't heavily use FTP though, mainly just FreeBSD packages/ports. I definitely noticed when it was broken, I couldn't download hardly anything from there.
9 : I'd like to see the pfSense install separated from the specific FreeBSD OS, treat it more like an application than a bundle - again there is much hardcoding in some php related to the OS version … this kind of thing makes maintenance very difficult especially when security fixes for embedded stuff like php are released.
That's hard to do, because there are a lot of OS patches and other bits that tie in specific to how a specific OS version behaves. For one small example, netstat output on 7.x is different (by a lot) than that of 8.x (and even some betas) so special handling is needed there. Being OS agnostic is just not feasible.
-
Thanks for the response, I'll see what I can do on the IPSEC stuff, the remote logs could be a problem as I do a lot for … a couple of security sensitive companies ... whilst I don't see a risk in posting those logs you can be pretty sure that somebody at the respective corporate HQ's would.
The IPSEC wouldn't even connect, didn't seem to even try and the remote logs didn't show any attempted connection either, the config was never redone, it was working at 1.2.3, upgraded, never worked again, downgraded (as in re-installed) and now working again.
Never managed to get the Cron to E-Mail, the log says that it is but is getting 'status 0x0001', for E-Mail purposes I trapped the Cron messages in my syslog app and got it to send the E-Mail ... it would be nice though to get an error when a job failed. I did play around with the MAILTO option (can't even find the crontab in V1.2.3), even tried adding SMTP entries for the php.ini.
01-11-2010 14:00:01 Cron.Info n36-gate Nov 1 14:00:00 cron[21223]: (root) MAIL (mailed 25 bytes of output but got status 0x0001 )
01-11-2010 14:00:01 Cron.Info n36-gate Nov 1 14:00:00 cron[21228]: (root) MAIL (mailed 28 bytes of output but got status 0x0001 )
01-11-2010 14:00:01 Cron.Info n36-gate Nov 1 14:00:00 cron[21230]: (root) MAIL (mailed 43 bytes of output but got status 0x0001 )
01-11-2010 14:00:01 Cron.Info n36-gate Nov 1 14:00:00 cron[21229]: (root) MAIL (mailed 29 bytes of output but got status 0x0001 )
01-11-2010 14:00:01 Cron.Info n36-gate Nov 1 14:00:00 cron[21225]: (root) MAIL (mailed 30 bytes of output but got status 0x0001 )With regards a quality graph for latency data I agree -I would and do have a use for that just not at the same frequency once a minute is more than enough for me, I am only interested in spotting potential throttling (although my ISP insist they don't I am not sure I believe them), I used to use an external source to do latency tests but they have long since disappeared, either way if it is configurable (or going to be) then it isn't an issue. I set the alarm limits and times to ludicrous values i.e worst case latency in excess of 30000ms, lost packets at 80%, alarm delayed by 10 minutes etc but still got reports and dropped states.
As for FTP I had scheduled remote locations to FTP their logs and some other stuff across but it failed and was failing up to Saturdays build, it is a time consuming pain to have to log into each one separately and transfer. This did seem to improve a little after I figured out how to kill apinger but it didn't fix it.
I need time to set up a developer box that I can just plug in and muck around as and when I can afford breaks in my connection - too much downtime if you screw up otherwise ;-). Once I do that I will see what I can do about the IPSEC logs, not sure how to test the FTP since there is nothing reported as an error, works OK for a time then just stops working.
I need pointers on what and where to look, even how to get the info needed to resolve items, I am not a dummy but nor am I a coding expert or a FreeBSD expert (although the pfSense install does seem a little 'non standard' so files aren't always where I expect them to be - could be wrong though).
-
Hi,
just wanted to say that ipsec (with certificates) works for me since about 4-5 months. I have 4 remote sites connected and never had a problem after setting it up.
Maybe you tried with some bad snapshots?
