FAIL on my part: I had done a wireshark, checking for LAN & WAN addresses (see post #8). I used a capture filter and TYPO'd the IP for the WAN (got the LAN right, but that didn't matter). It was only by one digit…  :( Would have been good to know 2 days ago.

From my understanding, the ISP must set the IP for you. If you have more that one, then your WAN will take on the first one and you will setup proxy arp or perhaps ip alias for the extra.

Thanks, that worked!

@wallabybob: PPPoE log should be found in Status -> System Logs, click on PPP tab. I have found on my pfSense 2.0.1 system that the PPP log is sometimes empty even though PPP has successfully started. Not all PPP users seem to have had this problem. I got this in the logs: Apr 26 17:10:49 ppp: [wan] IFACE: Close event Apr 26 17:10:49 ppp: [wan] IPCP: Close event Apr 26 17:10:51 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Apr 26 17:10:51 ppp: [wan_link0] Link: DOWN event Apr 26 17:10:51 ppp: [wan_link0] Link: giving up after 29 reconnection attempts Apr 26 17:10:51 ppp: [wan_link0] LCP: Close event Apr 26 17:10:51 ppp: [wan_link0] LCP: state change Starting --> Initial Apr 26 17:10:51 ppp: [wan_link0] LCP: LayerFinish Apr 26 17:10:51 ppp: [wan_link0] LCP: Down event Apr 26 17:10:51 ppp: [wan] Bundle: Shutdown Apr 26 17:10:51 ppp: [wan_link0] Link: Shutdown Apr 26 17:10:51 ppp: process 22392 terminated Apr 26 17:10:51 ppp: Multi-link PPP daemon for FreeBSD Apr 26 17:10:51 ppp: Apr 26 17:10:51 ppp: process 63995 started, version 5.5 (root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org 10:25 12-Oct-2011) Apr 26 17:10:51 ppp: web: web is not running Apr 26 17:10:51 ppp: [wan] Bundle: Interface ng0 created Apr 26 17:10:51 ppp: [wan_link0] Link: OPEN event Apr 26 17:10:51 ppp: [wan_link0] LCP: Open event Apr 26 17:10:51 ppp: [wan_link0] LCP: state change Initial --> Starting Apr 26 17:10:51 ppp: [wan_link0] LCP: LayerStart Apr 26 17:10:51 ppp: [wan_link0] PPPoE: Connecting to 'Skynet' Apr 26 17:11:00 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Apr 26 17:11:00 ppp: [wan_link0] Link: DOWN event Apr 26 17:11:00 ppp: [wan_link0] LCP: Down event Apr 26 17:11:00 ppp: [wan_link0] Link: reconnection attempt 1 in 4 seconds Apr 26 17:11:04 ppp: [wan_link0] Link: reconnection attempt 1 Apr 26 17:11:04 ppp: [wan_link0] PPPoE: Connecting to 'Skynet' Apr 26 17:11:11 ppp: Multi-link PPP daemon for FreeBSD Apr 26 17:11:11 ppp: Apr 26 17:11:11 ppp: process 46058 started, version 5.5 (root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org 10:25 12-Oct-2011) Apr 26 17:11:11 ppp: caught fatal signal term Apr 26 17:11:11 ppp: [wan] IFACE: Close event Apr 26 17:11:11 ppp: [wan] IPCP: Close event Apr 26 17:11:11 ppp: waiting for process 63995 to die... Apr 26 17:11:13 ppp: [wan] Bundle: Shutdown Apr 26 17:11:13 ppp: [wan_link0] Link: Shutdown Apr 26 17:11:13 ppp: process 63995 terminated Apr 26 17:11:13 ppp: waiting for process 63995 to die... Apr 26 17:11:13 ppp: web: web is not running Apr 26 17:11:13 ppp: [wan] Bundle: Interface ng0 created Apr 26 17:11:13 ppp: [wan_link0] Link: OPEN event Apr 26 17:11:13 ppp: [wan_link0] LCP: Open event Apr 26 17:11:13 ppp: [wan_link0] LCP: state change Initial --> Starting Apr 26 17:11:13 ppp: [wan_link0] LCP: LayerStart Apr 26 17:11:13 ppp: [wan_link0] PPPoE: Connecting to 'Skynet' Apr 26 17:11:22 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Apr 26 17:11:22 ppp: [wan_link0] Link: DOWN event Apr 26 17:11:22 ppp: [wan_link0] LCP: Down event Apr 26 17:11:22 ppp: [wan_link0] Link: reconnection attempt 1 in 3 seconds funny thing is, if I use my laptop (Win 7) to do a pppoe connection everything works.

Well first thing I would do is turn off private IP blocking in the WAN interface properties. Then I would check subnet masks to make sure there is not overlap. Then I would make sure my default gateway is set to 192.168.2.1. I would also check traceroute to see where thinks break down. I would also check tcpdumps at the various NICs to see where it stops.

Or install the System Patches package and apply the following patch: https://github.com/bsdperimeter/pfsense/commit/d5d1554278233af6817d14a5a33444e2fdb7f1b9

@marcelloc: Frater,  hide you public IP address and pasword from your post. Those were fake… But thanks for your concern... I can't edit my post, but I saw a little error in the first wget where I hardcoded the --no-check-certificate That option is inside the variable "${WGETOPT}"  wget -qO/dev/null --keep-session-cookies --save-cookies /tmp/pfsense_cookies.txt  --post-data "login=Login&usernamefld=${USER}&passwordfld=${PASS}" ${WGETOPT} ${PROTO}://${IP}:${PORT}/diag_backup.php  wget -qO${FNAME} --keep-session-cookies --load-cookies /tmp/pfsense_cookies.txt  --post-data 'Submit=download&donotbackuprrd=yes' ${WGETOPT} ${PROTO}://${IP}:${PORT}/diag_backup.php I don't know if anyone will be using it, but if it even helps only one man it was worth posting it.

:D Sometimes 2" is more than enough! Steve

You need to introduce a delay to allow USB devices to be detected (option 3 does this) as detailed here: http://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_from_USB Steve

So you have a triple NAT going on??  Why? Devices connected to your linksys are on a 192.168.2.0/24 network, then it nats to a 192.168.5.0/24 network, then it nats again 192.168.1.0/24 network and then finally public ip outside your uverse?? Why in the world would you set it up like that?? If your going to use your linksys as AP, then it would be on 192.168.5.0/24 network, all your clients would be on 192.168.5.0/24 then your only doing a double nat.  Again why? Can you not use your uverse box as bridge only?  So pfsense gets public on its wan interface, and then you would only have single nat, which is a normal setup.

So you have it booting successfully? Do you mean tips for pfSense in general? Steve

The upgrade works fine for most people. All known issues are listed here: http://doc.pfsense.org/index.php/Upgrade_Guide Pay special attention to: http://doc.pfsense.org/index.php/Upgrade_Guide#International.2FSpecial_Characters_in_1.2.x_Configs We are also preparing the 2.0.2 release which includes several more upgrade fixes, but I don't recall if any of them would have resulted in any sort of crash.

@gderf: Looks like you are trying to boot a 64 bit version of pfsense on a 32 bit platform. :o  :o  :o Oh my god… you are right! Just confused by the file names  :-[ Sorry and thank you anyway for your time.

I have port forwarding on my WAN interface. I followed your steps A and C (B and D are unnecessary). Port forwarding is discussed on page 130 and following in the book "pfSense The Definitive Guide …" You haven't provided any information suggesting you should bridge WAN and DMZ. I don't know the details of the ordering of input processing but it is possible the bridge code will decide packets arriving on the WAN interface are for pfSense itself before the port forwarding can take effect. Note that it is sometimes necessary to reset firewall states after significant changes to the firewall rules - see Diagnostics -> States, click on Reset States tab. On removing the bridging it might be necessary to reboot for that configuration change to fully take effect.

You don't need to reset to defaults. Easiest way overall (for me anyhow) would be to download the config.xml and search/replace the old card with the new card, then restore the backup and let it reboot. Easiest way in the GUI, if both cards exist at once, is to create the tags on the new card and then reassign them. After you confirm they work on the new card, remove the tags from the old card, then take the old card out.

@jimp: Unfortunately unless you have some experience with unix it will be hard to manually recover from that missing library. Since you can't do an automated upgrade/firmware application, you'd have to manually transfer the fimware image to the firewall and unpack it manually to restore that library. Alternately, you could reinstall+restore your config, which would be a lot easier. That doc wiki link is talking about putting the config on a USB stick on the firewall. Thanks.  I tried that earlier this morning, and after installing from the LiveCD with the USB flash drive containing the old config files plugged in, the pfsense box rebooted and came back up with what look to be the previous settings (at least the IP info on the boot menu screen).  It's not hooked up to anything so I won't really know if it was truly successful until I take it back out to the remote office location and hook it back up.

You don't need anything special for handling a large hard disk beyond what you would need for the package itself. A 1 TB Squid cache would require about 10 GB of RAM however…

[2.0.1-RELEASE][root@pfsense.my_domain.com]/root(3): netstat -m 1036/764/1800 mbufs in use (current/cache/total) 769/599/1368/25600 mbuf clusters in use (current/cache/total/max) 768/384 mbuf+clusters out of packet secondary zone in use (current/cache) 0/27/27/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1797K/1497K/3294K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/8/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines

Wasn't sure where the bug tracker was, thanks.  Bug 2564.

@sgb: Thanks cmb.  Seeing as how the CARP IPs are already in place and the enumeration may be a problem, I'll schedule a full outage on the cluster. Not necessary, I've walked people through a number of such NIC additions with no issue. Do the secondary first, see if its NIC assignments have shifted, if so reassign the NICs (there will be no adverse consequences, but to make 100% sure of that, only plug it into a test network to see how the NICs get addressed). Then you know what to expect on the primary. It would be prudent to do it at a time that is as best possible in case you take them both down for some reason.