bonnie222,
I have to agree with johnpoz. You have something going on with your DNS configuration. Have you checked your DNS settings to make sure you have a DNS server configured? Can you successfully look up A records for sites like www.pfsense.org and files00.netgate.com. If you can't do A record lookups you certainly aren't going to be able to do SRV record lookups.
There is an option under 'System -> General Setup -> DNS Server Settings' that allows your ISP DHCP settings to override the local DNS server settings. If you are using DHCP from your ISP and using their DNS servers make sure this is checked. This should not be unchecked unless you have your own DNS servers, you want to use different DNS servers (like google), or your ISP doesn't provide DNS via DHCP. If the box is unchecked you have to manually configure DNS servers.
If your box has Internet access to google's DNS servers you can test by using 8.8.8.8 as a DNS Server, uncheck 'DNS Server Override" and check the "Disable DNS Forwarder'. This will skip using the pfSense box for DNS and go directly to Google's DNS server. If this works then either your ISP isn't providing a DNS server via DHCP and you need to configure a DNS server manually or your own DNS server is filtering what you are allowed to resolve.
Hope this helps.
@cmb:
If your gateway monitoring isn't working post-2.3 upgrade, it's likely one of two things.
Verify advanced options are sane
Browse to System>Routing and edit the gateway that's down. Then click Save. That will trigger the input validation that makes sure the configuration is valid, especially the advanced options. You may have had options set for apinger that are not valid for dpinger. If you get any errors upon saving, fix them, save, and apply changes.
Set ping payload size
Some modems have a bug that makes them drop pings with 0 byte payloads. dpinger uses a 0 byte payload by default because there isn't a need to include one and unnecessarily chew up bandwidth. If you have such a buggy upstream device, you'll need to set the payload to something greater than 0. System>Routing, edit the gateway, go to Advanced, and set payload to 1. Save and apply changes.
Yes, it works again ;D
Good Question @johnpoz
No, I don't have Telnet exposed. If I understand the vulnerability correctly, it doesn't matter what ports are exposed because the frame won't be dropped until it's reassembled - which doesn't happen before the crash. (If I have that wrong, please correct me.)
From the CVE, "An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system's network performance and/or consume excessive CPU by exploiting the inefficiency [the algorithm used in FreeBSD v10/11] of TCP reassembly handling ... ". This CVE is the only explanation I could come up with for the frequent, recurring crashes of my Netgate appliance - all within the past week.
The logs I reviewed didn't clearly/directly indicate the reason for the crashes, though the first several crashes did show packets arriving from "Poor Reputation" (Snort) IP addresses, port 23. Regardless, my assumption about a Telnet session as the culprit appears spurious now. Crashes, after my original post, didn't have the same port-23-associated log entries just prior to the crash. Sadly I'm not skilled enough to dive deeper with equipment on hand. I never actually saw a CPU spike indication, but I'm guessing the 'degraded network performance/excessive CPU consumption' can occur without seeing indicators in real-time reporting information.
The crashes that have occurred required unplugging the firewall, then rebooting (with reset for >5-10 seconds after powering up) to get the appliance to boot normally. Unfortunately the crashes recurred - presumably after a scan found my FreeBSD machine operating again - typically 30-120 minutes later.
My interim solution: I put a non-FreeBSD router between the ISP and local network, so the FreeBSD firewall isn't directly exposed. Not my preferred long-term solution, but hopefully it holds till the OS update is available. No crashes in over 4 hours now, so it seems to be working (and also seems to validate a WAN-based cause for the crashes).
If ANYONE has a better/alternative explanation to my woes, I'm all ears!
Should I Do a restart after disable of Pf blocker ? Will take a look at the reddit post thanks guys!
Do you think the Cpu problem is just like the Ram one ? Hey I will try any thing with in reason.
My best fix yet is to set var/ to as a ram disk and it does not allow it to go over the set parameter.
Will Disable and update my post It takes around 2-3 day's to for the memory to hit 99%.
I change Cron to 4h set logging on unbound to level 3 as it was on level 2.
unbound-control -c /var/unbound/unbound.conf status (Edit2)
@stephenw10
thanks a lot, i boot it from another Computer with 2 Network_card, had Access to web_GUI. and changed what you said: - System > Advanced >Serial console enabled,
- System > Advanced >Miscellaneous: moved /var and /tmp to RAM
and now it works in my Hardware as well.
@derelict Ok, so 2.4.4 definitely got me the driver. Separately, moving from my old to new was a bit clunky.
Upgraded my old from 2.4.3 to 2.4.4, backed up config.
Uploaded new config to my new box, prompted me to adjust the interfaces then apply.
Hit apply, it complains about the browser not supporting cookies.
I tried being smart and manually adding "cookie_test" that it was looking for but nothing. I'd enter in the correct credentials, it'd refresh but not redirect. Eventually I think it rebooted, and I couldn't access it. I then determined it applied my config but not the interfaces. I set the interfaces to the correct ones, but still not accessible. When I reset webConfigurator password, then everything kicked in. I think it had something to do with backing up on an HTTPS to an HTTP. My old box was using HTTPS on 4443. Best guess anyway.
A reinstall is probably easiest.
If your WAN is DHCP you might be able to get away with running dhclient em0 where em0 is the actual WAN interface. If it's static or something else it could be done but it would be more difficult.
When you reinstall, choose the option to recover config.xml and it will pull your current settings back in.
No, you cannot use 2.4.4 packages on 2.4.3. Load the pfSense 2.4.4-RC and keep trying to figure out what is happening that prevents it from working for you.
If a problem doesn't get found and fixed in the snapshots or RC it will still be a problem in the release. But since nobody else is hitting that issue but you, you need to do some debugging to figure out what is wrong with your configuration that triggers the problem.
So you are routing the /30 to pfSense, from the the edge router?
And then routing it to the Mikrotik?
None of that is Layer 2.
We are going to need a full diagram here with all the interfaces on each device and the IPs shown. It's not at all clear what you have here.
Also a clear definition of what you trying to achieve.
Steve
So it's the LTE modem that is bridged to the pfSense WAN? But it still uses a private subnet? Or is that just for accessing the modem?
2-3 hours is an unusual time span. What do the pfSense system logs show? Does the modem log anything?
Steve
That's the only file you should need.
If you had any packages installed it will try to re-install those at the first boot after uploading the config. If you don't have a valid WAN at that point it cannot do that.
How exactly did it 'brick'? Do you still have access to the console?
Steve
For refernce you need to use a FAT32 formatted USB stick for PFI or ECL. Since the installer image is UFS that generally means using a separate USB stick to hold the config.
Packages should be re-installed automatically when you restore the config. If you didn't have a valid WAN interface at that point that process would fail. The package config is retained though.
Steve
I just installed the latest 2.4.4 Development FreeBSD 11.2-RELEASE-p2 and its working with Apollo lake. No more HPET error.
Also restore from previous backup from 2.3.5 and everything work pretty well.
Package running on OpenVPN, Suricata and PFblockerNg.
I had a little spare time to test few things.
restore config.xml (2.3.5) with fresh install of 2.3.5 = fail
restore config.xml (2.3.5) with fresh install of 2.4.3 = fail
edit config.xml (2.3.5) and removed the ACME package = worked in 2.3.5 and 2.4.3
uninstalled ACME package prior upgrading from 2.3.5 to 2.4.3 = worked
So the ACME package was breaking the upgrade/restore, it should be obvious, because ACME depends on a php56 package, which is causing a conflict.
OK thanks for the heads up. What about setting it up this way is un-secure? Also I have actually setup pfsense on a flash drive qnd run it this way instead. Anything i should know about running pfsense in this manner? Thank You!
We "image" the pfsense routers once a week. As far as I remember none of the pkg commands worked - pkg-static ..etc, and thats why we werent able to install any packages either. But as said before, since I have reinstalled the server it works again. If it happens again I will try and look at the image and see what changed and maybe get an idea why it stops working.
Thanks for the help anyway.
Out of interest what version was it you needed and what reason do you have for needing it?
I can't think of anything of hand that should not on 2.3.5 at least.
Steve
@jonanddad said in Trying to upgrade from 2.3.1 issues:
Shell Output - echo yes pkg-static install -f pkg
yes pkg-static install -f pkg
Not like that.
I was only checking if your "y" key on your keyboard is working.
I presume you entered y or Y here :
@jonanddad said in Trying to upgrade from 2.3.1 issues:
Proceed with upgrade? (y/N) read: read error: Socket is not connected
and then you had the
error: Socket is not connected
message.
Seems more like some network error, occurring when the upgrade starts.
edit :
I just ran pkg-static install -f pkg
[2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: pkg-static install -f pkg
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be DOWNGRADED:
pkg: 1.10.5 -> 1.10.3_1 [pfSense]
Number of packages to be downgraded: 1
3 MiB to be downloaded.
Proceed with this action? [y/N]: Y
[1/1] Fetching pkg-1.10.3_1.txz: 100% 3 MiB 233.2kB/s 00:13
Checking integrity... done (0 conflicting)
[1/1] Downgrading pkg from 1.10.5 to 1.10.3_1...
[1/1] Extracting pkg-1.10.3_1: 100%
You may need to manually remove /usr/local/etc/pkg.conf if it is no longer needed.
As you can see, I hit "Y" and the install (downgrade ;) ) continued.
Btw : I'm using 2.4.3-RELEASE-p1 - surely not the old 2.3.1.
edit 2: check out the forum, and you will find many issues when upgrading from old versions.
Keep it mind it will take a couple of seconds to download the latest pfSense version.
Some more seconds to export your config.
A minute or so to build a bootable USB stick.
Some more minutes to install from the USB stick.
A minute to have LAN working.
A couple of seconds to import your settings.
A couple of minutes for pfSense to re install your packages, if you have been using any.
And your done.
Hi,
So,
@fuzzywuzzy said in Cant ping LAN interface:
192.168.0.1
is the IP of pfSEnse.
What did you enter as mask ? "24" ? Something else ?
Did you change the DHCP pool in consequence ?
What happens if you redo the initial setup using console access, and keep everything tod default (this works soooooooooooo good - that's probably the reason why they decides to take these values as default).
Hi ,
Yes the model is Zotac CI327 and yes the CPU is Intel N3450.
I've tried Ubuntu and it's installed and works just fine , I have the problem with pfsense only.
I can't find where to disable "Monitor M-Wait" in BIOS.
Everyone starts somewhere. It's a simple mistake.
I don't have a 2.4.3 box I can easily test that on but in 2.4.4 the console reports this when you set an interface IP:
You can now access the webConfigurator by opening the following URL in your web browser:
https://192.168.87.1/
Either way the subnet should not be part of the URL.
Steve
Hmm, weird. I've never seen that before.
Hard to imagine filesystem corruption causing that directly. Perhaps you had an unapplied change there?
It seems more likely it got part way through a boot at some point but I still can't see how it would have ended up with those ram drives. Another admin attempting to recover the firewall?
Steve
The certificate probably doesn't match the server name. You need to add the fqdn as an alternate name. I also added an IP address in there so I can connect either way. It worked here for me in Chromium after I imported the CA that signed the new cert.
Steve
What version of pfSense are you running?
libssh2 is not in the default install on 2.4.3_1 or 2.4.4 as far as I can see though so it was probably installed as a dependency of mc or someother package. If you upgraded since it may have been removed. Or if another package was removed that originally installed it.
It is in our repo though so you should be able to install it using: pkg install libssh2
Steve
Try going to System > Updates/Firmware and selecting the 2.3.X security/errata branch. No go back to the Dashboard and to force an update refresh. Check branch is still set to 2.3.X, set it again if it updated back to 2.4.X.
If it offers you 2.3.5_2 as an update go to that first then update to 2.4.3.
Steve
Hi jimp,
some good news here.
Your statement that "pkg can't reach the pfsense servers" pointed me to the right direction; I haven't understood it fully, but I found a way at least to unlock the pkg issue.
In my case, it was due to a double stack IPv4/IPv6 issue: to solve it, I had to temporaly disable the network interface linked to the GIF port; removing IPv6 name resolution plus removing the IPv6 default gateway and firewall rules to route IPv6 traffic didn't suffice.
I don't like to be so inaccurate in test results, but as IPv6 connectivity was actually working, defining this problem will require some more tests and I meant to find a quick workaround for everybody experiencing this kind of issue.
Let me know if this rings a bell.
@chris1bass said in pfsense not receiving a WAN address:
it did do a DHCP discover. But looks like it never got a response from the modem.
Well there you go explains why pfsense doesn't have a WAN IP, if it asks dhcp server for IP and doesn't get an answer - then no its not going to have an IP ;)
Work upstream to why offer is not being sent.
