Is there possibility to that pfsense itself can't use failover dns

This happened again this morning. There is something that is odd though. My work VPN was still up and working perfectly fine even though I could not get out from any other computer or start a new VPN on any other computer. Here are the logs.
Aug 3 09:10:48 dhclient: Creating resolv.conf
Aug 3 09:10:48 dhclient: RENEW
Aug 3 07:25:36 dhclient: Creating resolv.conf
Aug 3 07:25:36 dhclient: RENEW
Aug 3 05:41:11 dnsmasq[56541]: using nameserver 160.7.240.20#53
Aug 3 05:41:11 dnsmasq[56541]: using nameserver 160.7.240.4#53
Aug 3 05:41:11 dnsmasq[56541]: reading /etc/resolv.conf
Aug 3 05:40:02 kernel: Bump sched buckets to 64 (was 0)
Aug 3 05:39:58 apinger: Starting Alarm Pinger, apinger(5564)
Aug 3 05:39:58 check_reload_status: Reloading filter
Aug 3 05:39:57 apinger: Exiting on signal 15.
Aug 3 05:39:57 php: : rc.newwanip: on (IP address: 67.199.161.84) (interface: opt1) (real interface: rl0).
Aug 3 05:39:57 php: : rc.newwanip: Informational is starting rl0.
Aug 3 05:39:54 check_reload_status: rc.newwanip starting rl0
Aug 3 05:39:54 dhclient: Creating resolv.conf
Aug 3 05:39:54 dhclient: Adding new routes to interface: rl0
Aug 3 05:39:54 dhclient: New Routers (rl0): 67.199.161.1
Aug 3 05:39:54 dhclient: New Broadcast Address (rl0): 67.199.161.255
Aug 3 05:39:54 dhclient: New Subnet Mask (rl0): 255.255.255.0
Aug 3 05:39:54 dhclient: New IP Address (rl0): 67.199.161.84
Aug 3 05:39:54 dhclient: ifconfig rl0 inet 67.199.161.84 netmask 255.255.255.0 broadcast 67.199.161.255
Aug 3 05:39:54 dhclient: Starting add_new_address()
Aug 3 05:39:53 dhclient: BOUND
Aug 3 05:39:53 dhclient: ARPCHECK
Aug 3 05:39:53 kernel: arpresolve: can't allocate llinfo for 67.199.161.1
Aug 3 05:39:51 kernel: arpresolve: can't allocate llinfo for 67.199.161.1
Aug 3 05:39:51 kernel: arpresolve: can't allocate llinfo for 67.199.161.1
Aug 3 05:39:51 dhclient: ARPSEND
Aug 3 05:39:50 kernel: arpresolve: can't allocate llinfo for 67.199.161.1
Aug 3 05:39:49 kernel: arpresolve: can't allocate llinfo for 67.199.161.1
Aug 3 05:39:48 dhclient: PREINIT
Aug 3 05:39:48 dhclient: Deleting old routes
Aug 3 05:39:48 dhclient: EXPIRE
Aug 3 03:39:47 dhclient: Creating resolv.conf
Aug 3 03:39:47 dhclient: RENEW
Aug 3 01:53:23 dhclient: Creating resolv.conf
Aug 3 01:53:23 dhclient: RENEW

Does anyone have any thoughts? I can't get connectivity unless I reboot the PFSense box.

fixed. it was a stale dhcp lease that i overlooked. …guess i need to release those lease a little bit faster  :D

thank you for the help.

i love this product more and more each day. i have a couple VERY expensive palo alto's sitting there collecting dust since i switched the pfSense. ...too bad i couldnt find a single one on ebay. the same goes with KEMP load balancers (which happen to be freaking awesome for exchange 2k10, sharepoint, and some other products) ....fairly cheap for load balancers too.. 15k for largers ones and 5k for smallers ones.

thanks again.

Good to hear. nice it's solved

If you want to have the same behaviour as previous snapshots just go to the traffic shaper and select the lan interfaces and remove the shaper for it.
Leave only the WAN ones.

Your issue is that PRIQ can specify bandwidth in only the root queue. So that is the reaon i tell you to remove put the interface bandwidth there.
Possibly at your speeds even increse the queue limit.

It doesn't get far enough for me to install to a hard drive.

I FINALLY (after like 10 hours) got the external usb to boot, but I end up with the same "manual root filesystem" error, but it does not give me any available interfaces :(

http://www.freebsd.org/releases/8.1R/hardware.html

Looks like you're out of luck until a version based on FreeBSD 8.2 or newer. You might want to give the m0n0wall 1.8 beta a spin.

Ok, somehow I solved it…
After this morning's update and reinstall of the package, the menù and service was still not there.
Since I have two pfSense machines (the primary is stuck on the updates before the Snort retire and update) I could compare the config files to see what was wrong...
In config.xml of the secondary machine there were missing:
Node Service <name>snort</name>, ...
Node Menu <name>Snort</name>, ...

I just added those two items, and now everything is working... if you need to investigate on why the package installer was unable to add this two nodes in the config files I can send the log files or all the info you need...

Thanks a lot,
Michele

Have you looked through the system log at the record the dynamic DNS service left of what it did: pfSense shell command # clog /var/log/system.log | grep -i dyndns

Yes, in fact the changes were signoficant.

Reading through the threads for the various bug reports that went into the driver patch for msk it seems that in fact there are samples of code in many of them and a lot dating from around the time of 8.1 rel. I think, as you said, I need to find exactly which code change is relavent to my NIC and patch the 8.1 source manually.

There is also a possibility of updating the 'firmware' in the nic to remove the problem condition in the first place. I'm looking into it.

Thanks again.

Steve

[NOTE: Your post had nothing to do with the topic you posted it under. Please start a new topic for a new issue]

July 4 was a snapshot. Just like the snapshot you're on now. Nothing was special about July 4 except it was the last snapshot before we branched 2.0.

Well if you have shared IRQs with the disk controller that might give you issues.
One last thing to try is if increasing kern.hz to about 4000 value helps.

Also you need to check how many queues are configured on the igb cards as well.

ok jimp, thanks.

Never mind, seems to be an ISP issue.

Well are you sure that your switch is not looping responses back?
Check the switch behavior on multicast traffic maybe something related there!

The interesting parts will be packet traces from master and backup,
also the output of sysctl -a | grep carp

I filed Bug #1730 which was rejected and listed as not an issue. This issue does appear to be fixed.

Using build 2.0-RC3 (amd64) built on Fri Jul 29 22:14:50 EDT 2011 I have verified this issue is fixed by disabling my rules to allow traffic to ports 519 and 520 on each interface that has these rules. I also rebooted both firewalls and tested DHCP on multiple VLANs.

Since setting hw.ath.bstuck to 8 this problem has almost completely disappeared for me.
I have had less than 10 stuck beacon reports in the last 4 days which, although still not great, means the logs are readable again.
At least they would be if they weren't full of messages from hostapd!  ::)
These need their own log section.

Steve

Well this is resolved. I appreciate the comments.
This firewall was setup with two interfaces one to each side of the network.
One of these interfaces would not connect to the webconfig at all, the other would
get you there but throw the HTTP error.
Come to find out the admin who put this box in documented the IP address of both interfaces
but did not document the third IP that he used for the webconfig.
I can get to it now.
Thanks,
Ken

@Wallabybob - Good to know about the case senistivity.