I think you need to set a Monitor IP for your GPRS interface gateway. The PPP gateway by default is and 10.64.64.X address which usually never answers ICMP requests. Your gateway needs to respond to ping or you need to set a Monitor IP for that gateway for failover to work correctly. GB

Thank you. But doesn't seem to run… Result: [2.0-BETA5][addo@pfnatte.home]/usr/local/etc/nut(51): cat /usr/local/etc/nut/ups.conf user=root [hp] driver=usbhid-ups port=auto [2.0-BETA5][addo@pfnatte.home]/usr/local/etc/nut(50): /usr/local/etc/rc.d/nut.sh start starting usbhid-ups Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) No matching HID UPS found Driver failed to start (exit status=1) usbhid-ups failed to start

@kaneda: Hello boys, I had a Cisco 877 connected using IPSEC against a pfsense 1.2.3 like a charm Cisco has Dinamic public ip, that refresh DynDns hostname and I use that hostname for config on both sides of VPN IPSEC config. I updated to 2.0 and noticed that the tunnel config uses IP address for config and dont refresh it, Each time it changes I have to enter on PFsense PHase1 and save it, then on logs I saw that it rewrites config with new IP with 1 output. vpn_ipsec.php: The command '/usr/local/sbin/racoonctl -s /var/db/racoon/racoon.sock reload-config' returned exit code '1', the output was '' It says that previus IP and new IP is the same but I dont belive it. Dont know exactly whats happening but this tunnel leave working and with 1.2.3. It never gone down. Anyone has experienced something like this? Hi, I have a similar problem: I have a pfsense 2.0-BETA4 with 1 WAN with Dynamic IP (PPPoE) and Dynamic DNS. and a IPSEC SITE to SITE VPN with a Linksys Router with Static IP. PFSENSE (WAN1)(dynamic IP/DNS) <–---------TUNNEL---------> (Static IP)(WAN1)LINKSYS RV082 The DynDns Updates work fine, but when I reboot the pFsense the WAN1 Dynamic IP changes, the Dynamic DNS updates are Ok, but the other end, the linksys reports that pFsense are declaring as their IP the OLD dynamic IP. This a line of log of the linksys: We require peer to have ID '189.XXX.133.2', but peer declares '189.XXX.201.225' 189.XXX.133.2  is the new IP 189.XXX.201.225 is the OLD IP I need to re-save the phase 1 to get connected. Is this a bug or only config mistake? Thanks in advance. Ricardo

Any takers?

You should probably post this things where jimp requested it… It would be better for all others that are not watching this topic here...

Argh, I'm an idiot! I added a reject rule at "Floating", but this is maybe stronger than my WAN/LAN pass rules! And I did only figure that out by clicking on the red "X", that opens a message, which rule made the reject. And this I only figured out after searching the web for a long time…

@krisken: @dreamslacker: Which router do you have running DD-WRT?  Not all routers that run DD-WRT have internal LAN switches that are VLAN capable.  Each router will have a different means of assigning the switchports for VLANs due to differing port and interface names. WRT54GL (linksys) That should work fine.  Just google for: DD-WRT VLANs One of the first few hits has a guide on setting up the switch port for VLANs on the WRT54 series. Here:  http://www.geek-pages.com/articles-for-geeks-mainmenu-2/1-latest/26-8021q-trunking-on-the-linksys-wrt54gsl-with-dd-wrt Then hobcobble the guide in your post to use the bridges to bridge each virtual BSSID to a VLAN instead. i.e.  Say you have VLAN 10 & 20 for private and public respectively then br0 members:  VLAN 10 and et0 br1 members:  VLAN 20 and et0.1 (virtual BSSID for public) Then select a port for the trunking and add VLAN10 and 20 to it.  You will also want to remove the lines related to DHCP since you want pfSense to handle that.

Arg… problem seems back again with: 2.0-BETA5 (i386) built on Thu Dec 30 20:41:42 EST 2010. That's very strnage because the upgrade to the release before this one have fixed my issue (meaning that after a reboot, my pppoe link was up) Romain

@dan2010: the problems seems to be in the driver. Please elaborate on what you think is the problem with the driver. An earlier reply said: @dan2010: I listened on the bge1 interface, when pinging from 192.168.22.22 to 192.168.22.1: 22:41:52.946586 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:41:53.696292 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:41:54.446601 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:41:57.452032 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:41:58.201741 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:41:58.952047 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:02.610887 IP 192.168.22.22.netbios-dgm > 192.168.22.255.netbios-dgm: NBT UDP PACKET(138) 22:42:02.612536 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:03.362246 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:04.112704 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:07.115135 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:07.864693 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:08.615152 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:32.031140 IP 0.0.0.0 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) 22:42:32.056039 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) 22:42:32.082290 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133 22:42:32.093840 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) 22:42:32.929051 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s) 22:42:35.085173 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133 22:42:38.085807 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133 22:42:47.130748 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:47.881055 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 22:42:48.631364 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST Why is there is no sign of the ping in that trace? Here is what a ping exchange looks like on my pfSense system: 22:45:06.736389 IP 192.168.11.241 > 192.168.11.173: ICMP echo request, id 9237, seq 66, length 64 22:45:06.736544 IP 192.168.11.173 > 192.168.11.241: ICMP echo reply, id 9237, seq 66, length 64

It's just letting you know you have to acknowledge the license if you want to use those particular drivers. Stupid licensing requirement from Intel on some of its wireless drivers. It's a lot of useless noise for a few drivers that aren't widely used, we may make those optional modules at some point to get rid of the noise for those who don't need them. As long as you don't have an Intel wireless card that needs one of those drivers, ignore it.

Same result for Thu Dec 30 build as reported on another thread.

This is on the latest update (from the autoupdater page) Dec 31 01:50:34 kernel: FreeBSD 8.1-RELEASE-p2 #1: Thu Dec 30 20:39:36 EST 2010 Dec 31 01:50:34 kernel: sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 i386 I have this a bit up in the log as well: Dec 31 01:50:48 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/lan-queues.rrd -t :lan:qInternet:qACK:qDefault:qP2P:qGames:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' Dec 31 01:50:48 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/lan-queuedrops.rrd -t :lan:qInternet:qACK:qDefault:qP2P:qGames:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' Dec 31 01:50:48 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queues.rrd -t :wan:qACK:qDefault:qP2P:qGames:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' Dec 31 01:50:48 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queuedrops.rrd -t :wan:qACK:qDefault:qP2P:qGames:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' Then a bit further down, I see: Dec 31 02:01:29 php: /status_rrd_graph_img.php: Failed to create graph with error code 1, the error is: ERROR: start (1293800400) should be less than end (1293778889)/usr/bin/nice -n20 /usr/local/bin/rrdtool graph /tmp/system-processor.rrd-8hour.png --start 1293800400 --end 1293778889 --vertical-label "utilization, number" --color SHADEA#eeeeee --color SHADEB#eeeeee --title "`hostname` - System :: Processor - 6 hours - 1 minute average" --height 200 --width 620 DEF:"user=/var/db/rrd/system-processor.rrd:user:AVERAGE" DEF:"nice=/var/db/rrd/system-processor.rrd:nice:AVERAGE" DEF:"system=/var/db/rrd/system-processor.rrd:system:AVERAGE" DEF:"interrupt=/var/db/rrd/system-processor.rrd:interrupt:AVERAGE" DEF:"processes=/var/db/rrd/system-processor.rrd:processes:AVERAGE" AREA:"user#990000:user" AREA:"nice#a83c3c:nice:STACK" AREA:"system#b36666:system:STACK" AREA:"interrupt#bd9090:interrupt:STACK" LINE2:"processes#cccccc:processes" COMMENT:"\n" COMMENT:" minimum average maximum current

Just started using pfSense so I was trying to test various network usage packages.

Gone with 2.0-BETA5 (i386) built on Thu Dec 30 11:06:13 EST 2010

Thanks for the info.

And everything work great!  Thanks!