Anybody? I'll settle for not knowing why this interface bricked itself as long as I can force its removal from my system. Is there a command line function that can force the removal of an interface?

Access pfSense via SSH, option Shell (8) and use the command: pfSense-upgrade -d This worked for me.

Out of just pure curiosity why are you wanting to install 2.3.0 vs 2.3.2 – you really should install current.

Got it, let me get DNS name resolution working across the tunnel from either LAN. Thank you for the lucid explanations.

Yes, using the serial memstick installer image (not the CD iso)

@johnpoz: When you say public do you mean guest wifi? I would prob let them just use the secondary link if your not using that in a load balance setup and all your normal business traffic is on the 20x20 without issues.  Once you have to failover to backup I would prob nix all the "guest" wifi traffic all together. Guest network = guest wifi / VLAN30 - it's a public hotspot using the captive portal. Thanks for the input. I'm open to other ideas.  We are wanting maximum uptime; CARP/ pfSync - but also not wanting to create unnecessary complexity.

Strangely enough no. It was on Legacy. I tried every mode the motherboard has…. What I have noticed now is that only 2.3 works the way I mentioned above. When trying 2.2 the USB return to sata doesn't work. Good luck guys

Do you still have a backup of that config with the users and groups? I'd be very curious to see what might have caused that.

@tsmalmbe: Hello all, I have tried to upgrade my nano-installation from 2.2.5 to latest 3.2.x without success. The upgrade stops (gets stuck for at least 10 minutes - haven't waited longer) at a message "RRD update WANGWXXXX" (or alike, do not remember exactly because the machine I'm running teraterm on does not have internet connectivity). To even get this far in the upgrade, I have deleted all RRD data and disabled RRD completely on my 2.2.5 (I had my disk fill up with RRD before doing this). I then assumed I wuold have no more problems with RRD - but even after disabling it seems that RRD data for LANGWxxxx and WANGWxxx is being created and now the WANGWxxx RRD data is causing me this problem. Is there a workaround or what am I doing wrong? Same thing happened to me when going 2.2.6 to 2.3.1. Very disappointing that you cannot do a regular ('vanilla' install, no mods or changes) upgrade without major hassle.

If you have the firewall disabled you sure and the hell are not forwarding anything because your not doing nat.. What are you wanting to forward too if you only have 1 interface? How about you draw up your network are they both rfc1918?, showing your networks on the wan and lan side.  Install pfsense clean don't freaking disable the firewall or nat and then its click click for a forward.  If does not work then see the above troubleshooting guide for where you made a mistake. I can tell from being on this forum for many many years that forward issues are 99.99999% of the time PEBKAC or that the traffic is just not even getting to pfsense for it to forward in the first place.  Which if port 80, yeah many an ISP block that inbound. [image: disablefirewall.jpg] [image: disablefirewall.jpg_thumb]

THANK YOU!!! I had the same problem and this fixed it for me.

well pfsense is not using the resolver (itself) its using google.  You sure you have the resolve enabled.  Your client did not get refused or servfail it got a timeout, like pfsense isn't even listening on 53??  Or maybe your connection upstream of pfsense blocks you from resolving??  Your isp blocking or intercepting dns to other than major players? Notice how mine comes back that it asked itself 127.0.0.1, why is your using google?  If using resolver mode the only dns listed in pfsense should be loopback. Even if pfsense couldn't do upstream queries it should come back with its own name.. blsljdsf.sjlfjdsfldsfdf.sljfdsldjfs Server:  pfSense.local.lan Address:  192.168.9.253 *** pfSense.local.lan can't find blsljdsf.sjlfjdsfldsfdf.sljfdsldjfs: Non-existent domain [image: pfsensedns.jpg] [image: pfsensedns.jpg_thumb]

@danioj: @jimp: You can see the servers in /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf But don't edit that file. Instead, make a host override in your resolver/forwarder (whichever you're using) to resolve pkg.pfsense.org to 162.208.119.39 (or whatever it resolves to for you on a system with connectivity. Hardcoding addresses like that is dangerous, however, as we could move that to another IP address at any time. i can't believe i didn't think of that myself. thanks very much. appreciate it. worked like a charm. for anyone else wanting to do the same thing and stumbles on this post, this is how it is done: assuming host is pkg.pfsense.org and that resolves to 162.208.119.39 services>dns forwarder>host overrides>add host = pkg domain = pfsense.org ip address = 162.208.119.39 description = pfsense updater override save apply :) 8)

I figured it out, my vmware networking was all messed up. I had to rebuild the esxi server and that resolved the issue. Thanks for the multiple ideas and all the assistance, greatly appreciated!

Wow what an old thread. Disclaimer: I have no idea how valid any of what I'm about to say is.  It is mostly just based on my limited observation and even more limited knowledge of the subject. It may be utter nonsense. I've been running full install pfSense on USB flash drives for a number of years.  With RAM disk enabled, and backup schedule for RRD at 9 hours, and DHCP leases 7 hours. The USB flash drives seem to last about a year before starting to go bad. They seem to start exhibiting file corruption.  Though one went sudden total failure (probably a critical block went bad).  Inaccessible/Undetectable.  Could even detect and use it in a PC. Not sure if the wear-leveling of USB flash drives is effective and able to detect and mark bad blocks within the active file system. Two possibility mitigation techniques. When a file is noticed to be corrupted.  Don't delete it or edit it.  Rename it.  Then restore a good copy of the file.  This may keep the bad blocks out of service so they don't become available for other write cycles. Re-install to recreate the file system from scratch so the bad blocks can maybe be detected and marked. Bare minimum fail safe:  Have handy, 1) installation media, 2) a good USB flash drive, 3) recent config backup.

That's what I'm saying also.

It's a good question. All I've got access to is the CLI so I think I'm good using those IP ranges, certainly it's never been an issue when I've installed on VMWare but if there is a command I can use to be sure and/or test this I'll happily give it a go!!

That did the trick! Thank you for your support.