The first error sounds like it's adding  the same host to a table twice.

Not sure about the second one.

do these still happen on a current snapshot?

@johnpoz:

just did a gitsync - and shazam there you go Working!

I don't really use it, but sure the guys that do will be happy its working again..  Sweet how some reporting of details and issue fixed..

Got to love the pfsense crew!  Thanks guys!!

Yep, quite impressive, Everything running smoothly, cant ask for more.

Yep. I committed the fix. Sorry I made the false assumtion.

You can build a package of it.
Presently, no its not supported but is not hard to make apcakge for it.
Just take a look at miniupnpd and change the different parts.

Well first you have to put the interface in promiscuous mode and second there is already a sysctl for sending data with the vip mac(net.link.ether.inet.carp_mac) set that to 1 and it will send traffic with vip mac.

Regarding 1) - I leave the default "pass all" rule on LAN as it is at the bottom. I make an alias for all my internal subnets - called "InternalSubnets". Then put a policy-routing rule above the "pass all" rule, that has source any, destination !InternalSubnets, gateway = desired gateway group.
This directs all traffic that is not internal, into the gateway group, which then works out how to get it out a WAN that is up…
Internal traffic falls through to the "pass all" rule, and gets routed by the ordinary routing table.

Didn't reinstall just upgraded. Cleared RRD data as it says to at http://doc.pfsense.org/index.php/Upgrade_Guide#Changing_architecture_.2832_bit_to_64_bit_or_vice_versa.29_during_upgrade

It helped. Somehow box with Update URL was empy. Thanks!

We get that info from the master TZ database, it's not ours. So if it's incorrect, it's incorrect higher up than we can control.

The TZ databases were just updated a month or two ago on 2.1 and 2.0.x, so it's possible that they relocated the definition or deprecated the Europe version.

I updated now my 4th pfsense from 1. Feb to 2.1-BETA1 (amd64) built on Fri Feb 15 04:33:17 EST 2013.
I have the same problem again.
If one interface unwired or for other reason down (gateway don't reply on ping) it reloads the config every 15 seconds.
Racoon is restarted cyclic and VPN is unuasable.

@Reiner030:

But I'm a little confused:

on my border gateway firewalls I can't set the 2nd gateway in this form

When I try to delete the gateway and set it completely news I got the error that it's in a GW group…
After removing it from my gw group I found  all my GW's tries ^^

old one:  xxxx:xxxx::fe
new one: xxxx:xxxx:0:ffff:1
new one: xxxx:xxxx:0:ffff:0:0:0:1

So there seems an IPv6 bug with GW within a GW group, too.

Bests

Reiner

I have confirmed that it's working now and updated the ticket. Forgot to post here, thanks for the reminder!

It turns out that I have two IPv6 "dhcpd" sections in my config.xml file, a <dhcpd6>and a <dhcpdv6>.  When I enable the dhcp server under the Services -> DHCPv6 Server/RA menu, an <enable>gets put at the end of the <dhcpdv6>block just before , and when i disable it the <enable>gets removed.

The strange thing is, when I remove the <dhcpd6>block, and try to disable the static IPv6 IP on the LAN interface, I still get the error " The following input errors were detected:  The DHCP6 Server is active on this interface blah, blah…"

And when I go to the Services -> DHCPv6 Server/RA -> Router Advertisements tab and ensure that the Router Advertisements drop-down is set to "Disable" and everything else is empty, then click save, the whole incorrect (quite old) <dhcpd6>block gets added back in, complete with the <enable>.  I am not sure where it is coming from, it seems to be a really old minimal set of values from when I was first setting up IPv6...

It seems that interfaces.php is looking somewhere else for the <enable>or not looking for it at all, or looking for something else entirely to determine if the dhcpd6/dhcpv6 server is running...

dhcpd6 is:

        <dhcpd6><lan><enable><range><from>2001:470:1:2:3::0</from>                                 <to>2001:470:1:2:3:ffff:ffff:ffff</to></range></enable></lan></dhcpd6>

dhcpdv6 is:

        <dhcpdv6><lan><range><from>2001:470:1:2:ffff:ffff:ffff:0</from>                                 <to>2001:470:1:2:ffff:ffff:ffff:fffe</to></range>                         <prefixrange><from><to><prefixlength>48</prefixlength></to></from></prefixrange>                         <ramode>disabled</ramode>                         <rapriority>medium</rapriority>                         <rainterface></rainterface>                         <defaultleasetime><maxleasetime><netmask><failover_peerip><domain>domain.loc</domain>                         <domainsearchlist>domain.loc</domainsearchlist>                         <ddnsdomain><tftp><ldap><nextserver><filename><rootpath><dhcpv6leaseinlocaltime>yes</dhcpv6leaseinlocaltime>                         <numberoptions><radomainsearchlist>domain.loc</radomainsearchlist>                         <staticmap><duid>00:01:00:01:c7:92:bc:96:00:01:02:03:04:05</duid>                                 <ipaddrv6>2001:470:1:2:1:2ff:fe03:405</ipaddrv6>                                 <hostname>mrtv</hostname>                                 <filename><rootpath></rootpath></filename></staticmap>                         <dnsserver>2001:470:1::1</dnsserver></numberoptions></rootpath></filename></nextserver></ldap></tftp></ddnsdomain></failover_peerip></netmask></maxleasetime></defaultleasetime></lan></dhcpdv6> ```</enable></enable></dhcpd6></dhcpd6></enable></dhcpdv6></enable></dhcpdv6></dhcpd6>

Renato has now done the last correction proposed and tested by me and commited it in this revision.
https://redmine.pfsense.org/projects/pfsense/repository/revisions/923e440b75eda660a5cdbd102912fe53d61d1237

//Danne

Works for me now also, thanks for the fix!

Bruce.

@MaxPF:

Ok, I set it to 300,000. How can I test the table usage by pfBlocker and bogons?

Use the following code on the command line to see the total usage

pfctl -vvsTables | awk '/Addresses/ {s+=$2}; END {print s}

or just use

pfctl -vvsTables

and manually check the different tables

Btw: You could try the following patch that updates the bogons update script
https://github.com/bsdperimeter/pfsense/pull/418

Hi,

@ermal:

You are marking the interface down which would not count in suppress_preempt.
There are still some rough edges in general with carp but if you do trigger a linkdown through cable removal or somesuch it will switch.

More improvements are expected in 2.1 for this since a lot of time has been spent to make carp stable enough to work the general situation that it work 98% of the time from our statistics.

ah ok thx… Then I'm only wondering how the writer of these posts have done it with marking interface down :D
But it works as expected when I'm disabling port on switch  - below documentation for other people.

One question left:
What happens if the gateway goes down (it's behind a switch, so "virtual" disconnection like the "interface down")?
Is it possible to use some mechanism to combine Gateway failover and CARP failover as group between master-slave pfSense boxes if the slave has still connection to the gateway?

Init state with Master/Slave:
[2.1-BETA1][root@gw1.zws8.local]/root(1): ifconfig | grep -e mtu -e carp
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
pflog0: flags=100 <promisc>metric 0 mtu 33664
wan_vip211: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 211 advbase 1 advskew 0
wan_vip212: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 212 advbase 1 advskew 0
lan_vip213: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 213 advbase 1 advskew 0
lan_vip214: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 214 advbase 1 advskew 0
opt2_vip215: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 215 advbase 1 advskew 0

[2.1-BETA1][root@gw1.zws8.local]/root(2): sysctl net.inet.carp
net.inet.carp.allow: 1
net.inet.carp.preempt: 1
net.inet.carp.log: 1
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0

Failover state (I've IPv4 & IPv6 CARP on same interface):
[2.1-BETA1][root@gw1.zws8.local]/root(3): sysctl net.inet.carp
net.inet.carp.allow: 1
net.inet.carp.preempt: 1
net.inet.carp.log: 1
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 2

[2.1-BETA1][root@gw1.zws8.local]/root(4): ifconfig | grep -e mtu -e carp
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
pflog0: flags=100 <promisc>metric 0 mtu 33664
wan_vip211: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: BACKUP vhid 211 advbase 1 advskew 0
wan_vip212: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: BACKUP vhid 212 advbase 1 advskew 0
lan_vip213: flags=8 <loopback>metric 0 mtu 1500
carp: INIT vhid 213 advbase 1 advskew 0
lan_vip214: flags=8 <loopback>metric 0 mtu 1500
carp: INIT vhid 214 advbase 1 advskew 0
opt2_vip215: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: BACKUP vhid 215 advbase 1 advskew 0

And after falling back all normal again:
[2.1-BETA1][root@gw1.zws8.local]/root(6): ifconfig | grep -e mtu -e carp
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
pflog0: flags=100 <promisc>metric 0 mtu 33664
wan_vip211: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 211 advbase 1 advskew 0
wan_vip212: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 212 advbase 1 advskew 0
lan_vip213: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 213 advbase 1 advskew 0
lan_vip214: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 214 advbase 1 advskew 0
opt2_vip215: flags=49 <up,loopback,running>metric 0 mtu 1500
carp: MASTER vhid 215 advbase 1 advskew 0

[2.1-BETA1][root@gw1.zws8.local]/root(7): sysctl net.inet.carp
net.inet.carp.allow: 1
net.inet.carp.preempt: 1
net.inet.carp.log: 1
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0

Bests

Reiner</up,loopback,running></up,loopback,running></up,loopback,running></up,loopback,running></up,loopback,running></promisc></up,loopback,running,multicast></up,running></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,promisc,simplex,multicast></up,loopback,running></loopback></loopback></up,loopback,running></up,loopback,running></promisc></up,loopback,running,multicast></up,running></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,promisc,simplex,multicast></up,loopback,running></up,loopback,running></up,loopback,running></up,loopback,running></up,loopback,running></promisc></up,loopback,running,multicast></up,running></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,promisc,simplex,multicast></up,broadcast,running,promisc,simplex,multicast>

I've been noticing the same issues,  mostly due to the unconstrained growth of the tcpdump process.  I filed a bug report: https://redmine.pfsense.org/issues/2819

I'll note that firewalls which leave the Web GUI exposed to internet traffic will also see a lot of memory growth in the PHP process for obvious reasons.  Don't do that.

Sorry I don't really have a good way to explain it but all the nics were still configured but the nat and fw rules were removed the packages were removed and any other configurations that have been made were set back to default besides the interfaces. I had snort, dans, squid, and openvpn all configured then when the issue occurred they were removed and/or reverted back to factory settings. Not sure of any other way to explain. I did find there was a backup and I reverted back to it and now things are back to normal. It started after the latest 2.1 update last night.