Happy to report that the VPN router has been stable since the update.

So if you are experiencing issues on a device that has seen multiple updates over the years, consider a bare metal rebuild.  It does not take long and can export and import all of the settings easily.

Looks to me like that second disk (ada1) has failed. There probably won't be any way around that without physically replacing the drive.

I will be keeping an eye out for 2.4.1 with 11.1.

Thanks again for the info, though  It was helpful.

–DT

@Derelict:

Yeah the management VLAN to unifi gear can be any VLAN but it has to be untagged (the PVID) to the APs/cloud key/"controller" app/etc. There doesn't have to be a wireless SSID on it at all.

When you set an SSID to have a VLAN traffic on that SSID will be tagged to and from the switch. If you do not set a VLAN it will be untagged along with the management traffic.

Found the appropriate link to this - it makes sense now, but it didn't when I read it before setup:
https://help.ubnt.com/hc/en-us/articles/219654087-UniFi-Using-VLANs-with-UniFi-Wireless-Routing-Switching-Hardware

Initially you need to adopt your UniFi access points or switches over the native untagged VLAN, and this will be the continued requirement. That being said, they do support L3 management, so your controller can be on a different L3 network (or remote, etc.).

I didn't realise that "adopt" was a Unifi "reserved" word.

Thanks again Derelict

Thanks, unlocking kernel did trick.

How exactly did you remove the interfaces?

If it is trying to assign things to interfaces that don't exist that is a problem. It would normally ask you to re-assign them if that happens but there are some types it does not check.

Steve

Hi;
Does bell use all that odd ip stuff like Telus. in other forums you have to allow bogon networks on wan and lan etc.
plus ports and 127.0.0.0/8 and some others through.
here are some more :
IGMP Proxy

Downstream LAN 192.168.x.x/24
Upstream  WAN 207.0.0.0/8 10.0.0.0/8

FW Rules on WAN:

Protocol UDP
Source 207.0.0.0/8, 10.0.0.0/8
Port *
Dest 224.0.0.0/4
Gateway WAN
Check off the Advanced option that allows IGMP.

Protocol IGMP
Source 207.0.0.0/8, 10.0.0.0/8
Port *
Dest 224.0.0.0/4
Gateway WAN
Check off the Advanced option that allows IGMP.

I'd wish they would kill wps and let me use a key if i had the cable I'd run a lan and go
I want to admin the wifi router as well and not have to unplug and plug into the router to be able to.
Can you pm me maybe we can chat about your setup see whats up??

@exoticsportcars:

I have bell fiber here with TV service.

I have my pfsense box directly connected to bell's ONT (modem).

Internet comes through via VLAN 35 with no issues.

TV uses VLAN 34 (36 is some areas) with a VLAN priority of 4. Without the VLAN priority, this will not work.
I have this VLAN bridged to my OPT1 port. From there I have a cable going to my PVR.
It gets the 10.x.x.x IP that it should from the bell network and everything works with no issues.

I have no other bell equipment in use other than the modem.

As for wireless, I just have an Ubiquiti AP connected to my switch.

From experience, the TV service runs smooth with practically no lag. The same cannot be said if you were using bell's router.

I'm guessing this setup would apply to pretty much any bell derived fiber service in Canada. The TV VLANs maybe different.

Thank you for the links and info.

From my experience it's almost impossible to satisfy these scanners with out of the box deployments / versions.

You can "self certify" yourself by either proving security fixes have been backported or remedies have been manually applied.

PCI compliance needs to be renewed every 90 days and we try to make the process as quick and painless as possible.

I was wondering if there is an easy way of quickly telling what's in a particular openssh version and what's not

Something like this for Debian:

https://security-tracker.debian.org/tracker/source-package/openssh

?

Try going back to the default DNS settings as a resolver instead of using google DNS. That's the way it works without you changing any settings.

Check to see if your clients are getting DHCP leases.

Using USB & Realtek NICs are both not recommended. The Realtek should be fine for low speed applications - the USB NIC, who knows. It could be your problem right now.

A better way to use you laptop for pfSense would be with a very basic & cheap web managed switch with 802.11x VLANs.

https://www.amazon.com/TP-Link-Gigabit-Ethernet-Managed-TL-SG105E/dp/B00N0OHEMA/ref=sr_1_2?s=pc&ie=UTF8&qid=1503616430&sr=1-2&keywords=web+managed+switch&refinements=p_n_feature_keywords_two_browse-bin%3A7306161011

@tcsac:

@jimp:

Under Update Settings, if you switch to Development Snapshots, does it find those files?

It's looking in the wrong place, but it's not clear why it's looking in that specific place when it doesn't seem to be doing that for anyone else.

That's what I assumed when I saw the -devel.  So I switched to development, it found those.  Switched back to stable, it found the RC.  Weird, but that works, thanks!

Smells a lot of my issue
https://forum.pfsense.org/index.php?topic=135618.0

/Bingo

Thank you all. Sorry I did not show a diagram. Since I have no other IP in the upstream LAN1 than the pfSense device, I now understand that I can keep this "Block private networks" ticked and therefore must keep it ticked. Thanks.

https://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write

@chpalmer:

Yes it is possible.  Happy reading!    ;)

https://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode

https://strscrm.io/bypassing-gigapowers-provided-modem.html

Nice. Thanks

Thanks. Tried todays build and am now up and running  ;D

@PiBa:

Can you try from console / ssh ?:

pkg update -f pkg upgrade -f

that worked.  its bizzar the update function isn't working for some reasons

When you setup, your aren't mixing up LAN and WAN - connected to the wrong port ?
By default, the LAN is 192.168.1.1/24 and DHCP is ON - just accept all the defaults.

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.

We did not try removing package prior to upgrade.

Thank you for checking scripts.

I think it's better to go https://forum.pfsense.org/index.php?topic=43574.585 and post your question again, just linking this topic, may be somebody can help you.