Tracked down the fix for this.

The tcpdump process that was logging from pf was being killed but not restarted as expected.

It'll be fixed in snapshots that pick up this commit (late today, tomorrow, etc): https://github.com/pfsense/pfsense/commit/32fb33927d51dd73ba9d0ef5b483efe66328c92c

I don't have one handy to try it with, but I believe that the traffic will just fall into the nether if you do that.

FreeBSD's IPsec code will grab the packets that match the Phase 2 and try to make them enter the tunnel if they reach the system. The way route-to works, the packet would be leaving the firewall, but still matching the P2, but perhaps exiting the "wrong" way and thus the IPsec code may not let it leave since to do so would be a security violation of the IPsec policy.

So, it may work. I'd be surprised if it did, but it's worth trying.

It is in the Global Settings. "Keep settings after deinstall"

No need for fail2ban, for the reason most people want it anyhow. We include a daemon that watches for failed ssh logins and blocks them after too many failed attempts (IIRC it's something like 5 failed logins in 15 minutes, or maybe the other way around…)

It sounds like ezjail is already installed. pkg_delete requires the complete package name including the version number, so check "pkg_info" and specify the full name, or use:

pkg_delete ezjail\*

@wallabybob:

Please provide the relevant sections of the system log and DHCP log. (It seems dhclient logging has recently moved from the system log to DHCP log which probably makes it a bit harder to determine the ordering of link-up/link-down, apinger, dhclient actions.)

I posted some log file excerpts over here: http://forum.pfsense.org/index.php/topic,64296.msg348618.html#msg348618 - probably forgot to provide that link in the here.

I had a scheduled power outage yesterday in the afternoon again (if you're curious: I had one or two unscheduled/unpexted power outages, and following these, I began debugging my frdige (the thermostat was broken, so I replaced it with an AVR and a 1wire temperature sensor). Unfortunately, I didn't provide an ISP connector, so I have to pwoer down the fridge to pull the microcontroller to update the firmware. Even more unfortunate, getting access to the power cable would require me to take apart about half of the kitchen - so laziness dictates that I just flip the fuse. Of course, the kitchen is on the same fuse as the living room, the terrace and my office room…).

Well, this time (firmware was that of the morning of July 28th), everything worked fine.

Okay, and here's the system log output from the WORKING bootup:

php: rc.filter_configure_sync: Adding TFTP nat rules Jul 28 20:15:04 php: rc.start_packages: Restarting/Starting all packages. Jul 28 20:15:01 ntpd_intres[79111]: ntpd exiting on signal 15 Jul 28 20:15:01 check_reload_status: Reloading filter Jul 28 20:15:01 check_reload_status: Starting packages Jul 28 20:15:01 php: rc.newwanip: pfSense package system has detected an ip change 5.147.73.95 -> 5.147.73.95 ... Restarting packages. Jul 28 20:14:59 php: rc.newwanip: Creating rrd update script Jul 28 20:14:59 php: rc.newwanip: Resyncing OpenVPN instances for interface WAN. Jul 28 20:14:55 php: rc.dyndns.update: phpDynDNS (klaws.selfhost.me): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Jul 28 20:14:54 php: rc.dyndns.update: phpDynDNS (ks.kicks-ass.org): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Jul 28 20:14:53 php: rc.newwanip: phpDynDNS (klaws.selfhost.me): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Jul 28 20:14:52 php: rc.newwanip: phpDynDNS (ks.kicks-ass.org): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Jul 28 20:14:52 check_reload_status: updating dyndns wan Jul 28 20:14:50 php: rc.newwanip: ROUTING: setting default route to 5.147.72.1 Jul 28 20:14:50 php: rc.newwanip: rc.newwanip: on (IP address: 5.147.73.95) (interface: wan) (real interface: em0). Jul 28 20:14:50 php: rc.newwanip: rc.newwanip: Informational is starting em0\. Jul 28 20:14:47 php: rc.linkup: ROUTING: setting default route to 5.147.72.1 Jul 28 20:14:47 check_reload_status: rc.newwanip starting em0 Jul 28 20:14:47 php: rc.linkup: HOTPLUG: Configuring interface wan Jul 28 20:14:47 php: rc.linkup: DEVD Ethernet attached event for wan Jul 28 20:14:44 kernel: em0: link state changed to UP Jul 28 20:14:44 check_reload_status: Linkup starting em0 Jul 28 20:14:34 php: rc.linkup: DEVD Ethernet detached event for wan Jul 28 20:14:31 check_reload_status: Linkup starting em0 Jul 28 20:14:31 kernel: em0: link state changed to DOWN Jul 28 20:14:20 ntpd_intres[79111]: host name not found: 0.pfsense.pool.ntp.org Jul 28 20:14:17 sshlockout[72494]: sshlockout/webConfigurator v3.0 starting up Jul 28 20:14:17 login: login on ttyv0 as root Jul 28 20:14:07 php: rc.start_packages: Restarting/Starting all packages. Jul 28 20:14:07 syslogd: kernel boot file is /boot/kernel/kernel Jul 28 20:14:07 syslogd: exiting on signal 15 Jul 28 20:14:07 php: rc.bootup: Creating rrd update script Jul 28 20:14:04 php: rc.dyndns.update: DynDNS (klaws.selfhost.me) There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface. Jul 28 20:14:03 php: rc.dyndns.update: DynDNS (ks.kicks-ass.org) There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface. Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:02 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:14:01 php: rc.bootup: Adding TFTP nat rules Jul 28 20:14:01 check_reload_status: Updating all dyndns Jul 28 20:14:00 kernel: em0: link state changed to UP Jul 28 20:14:00 check_reload_status: Linkup starting em0 Jul 28 20:13:59 kernel: em1: link state changed to UP Jul 28 20:13:59 check_reload_status: Linkup starting em1 Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:56 php: rc.bootup: Could not find IPv4 gateway for interface (wan). Jul 28 20:13:55 php: rc.bootup: Adding TFTP nat rules Jul 28 20:13:55 kernel: pflog0: promiscuous mode enabled Jul 28 20:13:55 php: rc.bootup: Resyncing OpenVPN instances. Jul 28 20:13:55 php: rc.bootup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf em0 > /tmp/em0_output 2> /tmp/em0_error_output' returned exit code '1', the output was '' Jul 28 20:13:44 sshlockout[9407]: sshlockout/webConfigurator v3.0 starting up Jul 28 20:13:44 sshd[9067]: Server listening on 0.0.0.0 port 22\. Jul 28 20:13:44 sshd[9067]: Server listening on :: port 22\.

With this WORKING case, I can also see the dhclient restart in the DHCP log:

Jul 28 20:14:47 dhclient: PREINIT

Well - I am not totally convinced that it depends onb the build whether this issue appears or not. At least I don't regular commits comments like "broke dhclient again after fixing it yesterday".

@doktornotor:

@zenny:

In case there is never-ending upgrade happening, just go to 'Diagnostics' >> 'Backup & Restore' and at the bottom of the page click on 'lock all packages' or something like that, and then reinstall broken packages again.

Well, there are not broken packages. This is an issue specifically with tinc.

I guess I am also talking about tinc. See this thread: http://forum.pfsense.org/index.php/topic,63889.0.html

It is not broken in my case. Rolled back to 18 July snapshot as there are some problems with pfBlocker with 25 July. ;-) But tinc upgrade works fine in both snapshots.

@jimp:

I'm torn because on the one hand, it makes them easy to distinguish, but on the other, I think it could look better with some better color choices than I made.

I documented the RRD color files pretty well when I did the update so if someone wants to come up with some variations (perhaps different colors for different themes), it should be much easier to jump in and figure out what goes where now.

A long time ago I posted about the default colors of the RRD. Even I made some suggestions at that time:
http://forum.pfsense.org/index.php/topic,16463.msg85559.html#msg85559

Also, check my last post in this topic above.

Check this one as well, for pfSense 2.1-RC0. This topic is in Portuguese, but easy to understand:
http://forum.pfsense.org/index.php/topic,55664.msg297449.html#msg297449

I'm just trying to share and help.

@mastahfr:

Sometimes it's working for me, sometimes it's not, I suggest it's a server problem and not your pfsense settings

It must be pfSense, because ate home (with a normal router), downloading from the same server never gives me problems.

Use clog to examine the log files in the shell.

Maybe someone on IPV6 can help.  Poor me.  I'm stuck on boring old IPV4.
I was considering going to IPV6 but right now can't think of a good reason.

http://w3techs.com/technologies/details/ce-ipv6/all/all

I'm waiting on usage to top 4%

Just installed the latest build, like the rest i can confirm that everything is solved !

PS, DHCP6C still isnt started, but thats not really a problem for me at the moment, would still require some investigation.

@johnpoz:

"one of the lookup fails that may cause problems that don't directly point to dns problems."

How is that?  That would be the first thing it would point too, if something doesn't load you would verify name resolution.  Once you verify name resolution, then you check connectivity.  Your name resolution problem may well be a connectivity issue.

Some websites don't load, images not working - so try a different snap?? Come on dude seriously??

It was not the first thing I did… Listen, I already know you're a genious, OK? As I didn't have any DNS problems the last years when some pages don't load correctly it wasn't the first thing to come to my mind. And unfortunately dig and nslookup behave quite differently form safari. It wouldn't have been the first time my multi WAN setup was causing problems and it wouldn't have been the first time 'trying another snap' would resolve it. Heck, the last few builds even crashed safari beta builds.

Have you tryed small partitions ?
I had a problem with all pfsense version on a new computer with a partition size higher than ~32Gb (can't be 100% sure about the actual size at witch it does not work)

Under "System:Advanced:Miscellaneous", you'll find the options for "Gateway Monitoring:State", where its says:

By default the monitoring process will flush states for a gateway that goes down. This option overrides that behavior by not clearing states for existing connections.

Yup, I think this is pretty well hidden. I would have expected it under "System:Routing:Gateways".

@rcfa:

@zenny:

DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2

As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)

Not sure that applies in a security relevant context. Usually upgrades mean bug fixes, and bugs are potential exploits. So as far as security relevant software goes, I'd like to be on the latest patch level of every single component of the system, as far as anyhow possible.

AFAIK, a bug means the system breaks, no matter to what extent. So bug fix is the part of the broken system. I do not deny that.

@rcfa:

I'm sure a few year old version would seem to work just as trouble free, until such point that someone uses a bug for an exploit and hacks the system.

New exploits can happen to any system any time because penetrators (particularly with APT guys) use newer methods than the newest that you think of! ;-) So there is always a risk of new exploits.

In some places I am using firewalls-cum-routers that runs on a single floppy disk on a very low-end machine, working without any problem since the last century. So it depends on sys-/net-admin.

@rcfa:

This is a very different scenario as a desktop OS and a word processor, where one can say: "If you could write with it a letter yesterday, you can write one tomorrow, so why bother upgrading and risking potentially incompatible changes?

Mostly frequent upgrades through upgrade managers is the problem with the one who uses sophisticated Xwindows systems, particularly in desktops. What I have seen is most of the computer users these days choose to upgrade stuffs automagically without knowing what they are doing to the system nor reading any changelogs or security advisory. They do it just because something is automagic!

I have seen even on the *nix systems like Debian, CentOS that sometimes things break because of incompatibility of libraries after an update which would have been working flawlessly earlier. Maybe that is the reason, pfSense team has chosen pbi which delivers both packages plus dependency libraries like in NixOS.

However, I am for upgrading for security vulnerabilities plus feature needs, not because it just says that there is something new in the market. If it works and safe, there is no need to upgrade. It's like marriage. ;-)

Ed Hillary was asked why he climbed Mt. Everest, his reply was "Because it is there." It does not mean that everyone has to climb Mt. Everest because it is there. Same applies to software upgrades, it is not always necessary to upgrade just because it is there!

I did some researching. Apperently pfsense announces the ipv6 addresses with 4 hours of preferred validity.

When the WAN interface gets resetted, there should be an announcement that the address is no longer valid, otherwise the problem from my last post occurs when your public prefix changes. However there is a catch. Windows has a "bug" that doesnt allow invalidated prefixes to become back active (as long as you don't reboot or reactivate your network card).

The questions are
-Does pfsense remember the old prefixes and does it send an invalid announce after the WAN connection has gone down?
-Does this happen when the checkboxes for request ipv6 thru ipv4 pppoe and request only prefix are checked?
-Does this only happen when the connection dies because of external influence or this also happen when the connection is reset because e.g. the WAN-if is reconfigured.
Why is the validity so extraordinary long. 4 hours seems a lot. 1 or 10 minutes seem more reasonable to me if you figure in that the timer gets reset to 4 hours every ten seconds…. Is this value configurable?

bye + thx,
Darky

What is described here is a known bug in pfsense, provide more detail here: https://redmine.pfsense.org/issues/3096

What is described here is a known bug in pfsense, provide more detail here: https://redmine.pfsense.org/issues/3096