fine ! i will try the latest snapshot then ! tanks !

Good point. https://github.com/bsdperimeter/pfsense/commit/f2ea45ef4717f489d40e93d392fa3355d22141a6 https://github.com/bsdperimeter/pfsense/commit/ee6bd11d4c2988a32050c19841bbcf080ed3e602

could it be that im getting a lot of these in systemlog, its totally filled with such entries, i have created a new thread for that kernel: altq: packet for vr0 does not have pkthdr

@frater: I would really like to have the reinstalling of packages as optional. Varnish and Squid take ages to upgrade and therefore significantly increase the down time of the router after an upgrade. I also noticed that pfblocker turns off after an upgrade. This may be due to the package itself and maybe is even deliberate. I'm using it to create some aliases for a port 25 block (It blocks all outgoing traffic to port 25 except for my home country). I would really like to be able to upgrade without these packages being reinstalled. Impossible on NanoBSD. On NanoBSD the update is written to a completely different slice on the CF/disk. There is no way to preserve or copy the packages from one slice to the other effectively. It would break more than you'd think it would help. If you're upgrading often enough that it's a problem, then you should probably not update so often, as you'll just end up wearing out that CF sooner rather than later. :-)

Yeah it's filterdns. There's an open thread for current issues with it. Though the thread topic is about too many processes, ermal is fixing things based on what is going on in that thread since the current issues are descendents of that one….

Work like it should be now. Thanks for your fast answer!

In addition to the other fixes I made, I just added some smarter code to the openvpn engine option that does better checking for not just the engines on the system but also which engines are actually usable. That way if something like this were to happen in the future, the VPN wouldn't have failed, it just would not have used the padlock engine.

You need the one that will come next or gitsync.

No Problem. Happy to help!.

Normally with anycast addresses you need a routing broker as BGP/OSPF. Anycast is no different from the normal ipv6 networking apart from the routing daemon handling the finding of the nearest neighbor by keeping the routing table correct.

@mcrook: BUMP Any ideas? I'm also using re* NICs and had a problem when going from 2.0RC3 to 2.0REL.  So for a long time I was running 2.0RC3.  I figure it would work itself out from a newer release.  Once 2.02REL came out I tried it again and I had the same issue where the WAN interface wouldn't work with DHCP.  What fixed it for me was manually setting the WAN interface to force 100BASET full duplex.  I'm not saying that's your problem since it appears you are getting an IP address (not sure if you're using static).  Wouldn't hurt to give it a try.

actually ermal would know better as he handles this i guess, im not the developer

Thank you Jimp and Phil for the replies. In both the environment there a no special rules or routing lines. Just a plain vanilla gateway, with a openvpn server virtual opt interfaces and one real wan interface, but not passing any traffic… Therefore I was triggered by the error message. I'm happy to mail you the ipadres of this testserver to have a peek. Regards, Martin

I finally worked out what was going on.  Two of my external wan routers didn't respond to ping… so the gateways were continually being marked as down. I changed the IP address that was pinged and routing started working and the check_reload_status process is now well behaved.

That one is unrelated. The dhcpleases error is not the one you're after. You'd want one from just dhcpd. Check the DHCP log tab.

Edit: found another thread with my real issue.

I'm going to fire up tcpdump and post the results shortly…

thanks. works fine.