Your cert info looks like this : -----BEGIN CERTIFICATE----- MIIEqzCCApOgAwIBAgIRAIvhKg5ZRO08VGQx8JdhT+UwDQYJKoZIhvcNAQELBQAw GjEYMBYGA1UEAwwPRmFrZSBMRSBSb290IFgxMB4XDTE2MDUyMzIyMDc1OVoXDTM2 MDUyMzIyMDc1OVowIjEgMB4GA1UEAwwXRmFrZSBMRSBJbnRlcm1lZGlhdGUgWDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK5478BAQDtWKySDn7rWZc5ggjz3ZB0 8jO4xti3uzINfD5sQ7Lj7hzetUT+wQob+iXSZkhnvx+IvdbXF5/yt8aWPpUKnPym oLxsYiI5gQBLxNDzIec0OIaflWqAr29m7J8+NNtApEN8nZFnf3bhehZW7AxmS1m0 ZnSsdHw0Fw+bgixPg2MQ9k9oefFeqa+7Kqdlz5bbrUYV2volxhDFtnI4Mh8BiWCN xDH1Hizq+GKCcHsinDZWurCqder/afJBnQs+SBSL6MVApHt+d35zjBD92fO2Je56 dhMfzCgOKXeJ340WhW3TjD1zqLZXeaCyUNRnfOmWZV8nEhtHOFbUCU7r/KkjMZO9 AgMBAAGjgeMwgeAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFMDMA0a5WCDMXHJw8+EuyyCm9Wg6MHoGCCsGAQUFBwEBBG4wbDA0 BggrBgEFBQcwAYYoaHR0cDovL29jc3Auc3RnLXJvb3QteDEubGV0c2VuY3J5cHQu b3JnLzA0BggrBgEFBQcwAoYoaHR0cDovL2NlcnQuc3RnLXJvb3QteDEubGV0c2Vu Y3J5cHQub3JnLzAfBgNVHSMEGDAWgBTBJnSkikSg5vogKNhcI5pFiBh54DANBgkq hkiG9w0BAQsFAAOCAgEABYSu4Il+fI0MYU42OTmEj+1HqQ5DvyAeyCA6sGuZdwjF UGeVOv3NnLyfofuUOjEbY5irFCDtnv+0ckukUZN9lz4Q2YjWGUpW4TTu3ieTsaC9 AFvCSgNHJyWSVtWvB5XDxsqawl1KzHzzwr1589F2rtGtazSqVqK9E07sGHMCf+zp DQVDVVGtqZPHwX3KqUtefE621b8RI6VCl4oD30Olf8pjuzG4JKBFRFclzLRjo/h7 IkkfjZ8wDa7faOjVXx6n+eUQ29cIMCzr8/rNWHS9pYGGQKJiY2xmVC9h12H99Xyf zWE9vb5zKP3MVG6neX1hSdo7PEAb9fqRhHkqVsqUvJlIRmvXvVKTwNCP3eCjRCCI PTAvjV+4ni786iXwwFYNz8l3PmPLCyQXWGohnJ8iBm+5nk7O2ynaPVW0U2W+pt2w SVuvdDM5zGv2f9ltNWUiYZHJ1mmO97jSY/6YfdOUH79RtQtDkHBRdkNBsMbD+Em 2TgBldtHNSJBfB3pm9FblgOcJ0FSWcUDWJ7vO0+NTXlgrRofRT6pVywzxVo6dND0 WzYlTWeUVsO40xJqhgUQRER9YLOLxJ0O6C8i0xFxAMKOtSdodMB3RIwt7RFQ0uyt n5Z5MqkYhlMI3J1tPRTp1nEt9fyGspBOO05gi148Qasp+3N+svqKomoQglNoAxU= -----END CERTIFICATE----- ? The "Certificate Private Key (optional)" is optional. Needed if you want to revoke the cert, something that has no real meaning for a "firewall GUI". Try with this part. Also : there is s/ was some cert issue, resolved in the 2.5.0 dev version. Check redmine.

@tlotr Lan ip? When something runs on pf, and makes a network connection to a remote host uses the local ip of the connected gateway to that host. I believe you are not "protecting" the ip used by ipsec phase2 Can you post your ip sec settings, especially p2 and a network diagram to make it clear.?

Sockstat seems to have helped. Looks like the cause is UPNP-PMPNat. I noticed a bunch connections on port 2189 from PFSense to my nas. Disabled these services and they seem to go away. Will see how the log looks in the am.

Update: I made the change suggested by @tman222 last week and have not had a single issue since then. Both phones now work fine, and it did not require any new NAT rule. The value of udp.multiple can probably be tuned as the "conservative" mode keeps connections open for a while. I also took a look at the internals of Android to figure out the default time between NAT-T keepalive packets. The constant of interest is (aptly) named NATT_KEEPALIVE_DELAY_SECONDS. Stock Android shows that it has a value of 10 seconds (probably why a Pixel phone works immediately), so either Samsung or all the US carriers are changing its value to something different. The constant is defined in the file IkeSessionStateMachine.java under com.android.internal.net.ipsec.ike. Thank you all!

https://github.com/pfsense/FreeBSD-ports/tree/devel/sysutils/pfSense-upgrade

Most of those are not relevant since they aren't even the right OS/Platform/etc. That doesn't even mention what port the notification was triggered by, but since they appear to be HTTP, probably the GUI. The ones that don't mention a specific name are very old, and I find it hard to believe they are still relevant against a modern nginx or haproxy like the one used on pfSense. Also, depending on how you performed the scan, if you have NAT rules, you might actually be scanning a device behind pfSense and not pfSense itself.

@netblues said in New, noob, just up and running and a little hiccup?: Browsers first try to connecti via ipv6. If they - the devices on a LAN - have an IPv6 that can route to the outside, and they have a IPv6 gateway. A solution might be : set IPv6 to None on the pfSense LAN interface setting. Devices on LAN can still communicate among each other using IPv6 using auto assigned IPv6 addresses - the fe80.... ones - but will not use IPv6 to visit "the world". [image: 1594618134192-414fbddf-419e-45ef-8b2a-abf4eac6c5c0-image.png]

@greymouser said in I cannot route between LAN and VLAN: Does it even need to be a VLAN if it's on it's own port? No it doesn't - but what are you connecting these ports too? You can not just connect them to a dumb switch.. You need to either use different dumb switches for your different networks. Or you need to be connecting to a single device. If your connecting into a switch - then you will need to setup up vlans on the switch for your different ports.. Pfsense doesn't have to know anything about them.

@Walter5623 said in Swap usage: Hi, Would useing RAM Disks help? Any other ideas? Cheers Using RAM disks will make your problem orders of magnitude worse! Do you know what swap is for and what it actually is? Swap memory is a type of temporary RAM. When there is not enough physical RAM to hold the information the currently running processes are using, the operating system will cycle currently idle sections of RAM out to a special file on the disk. So any currently loaded process that happens to be sleeping or otherwise not actively using CPU at that exact instant can have some or all of its data removed from RAM and written to the swap file on disk to free up RAM for use by another active process. Then, when that sleeping process "wakes up" and starts execution again, the operating system reads its data from the swap file and copies it back into RAM. This is an extremely slow set of processes compared to keeping the data in RAM the whole time. So usage of swap is basically to be avoided. When you start using swap, things are going to get very slow very fast. A RAM disk uses part of RAM to hold data that is normally written to disk. So you would be taking up even more precious RAM to act as a disk drive and thus increase the operating system's need to use the swap file. You leave the OS even less free RAM to use for processes since a RAM disk reserves some RAM to be a disk drive. RAM disks today are generally a bad idea on pfSense. I suggest you avoid using them altogether. As @DaddyGo mentioned, you are using some memory intensive packages. 4 GB of RAM is really not all that much for the packages you have. Are you sure you really need Squid? With the widespread use of HTTPS today, the utility of caching with Squid is reduced unless you are using some type of MITM. Squid can use a lot of disk space, too. The ntopng package can also be quite resource intensive as can Snort. So together, all those packages can give your firewall a real workout with only 4 GB of RAM available. That's why your firewall is resorting to use swap space, and it is having trouble even with that. This is because swap space is configured during pfSense installation and is a fixed size. Your error messages indicate you are exhausting your swap file space.

Removing the coax caused pfsense to lose connection, but maintain the DCHP address it had. I was logged in to the gui and could still use it as long as I stayed away from the dashboard. The dashboard did load very slowly but did load after a few minutes. Logging out and then logging back in, where the default starting point is the gui, did not ever load and eventually returned this: [image: 1594594724498-screen-shot-2020-07-12-at-4.51.54-pm.png] I read this is due to widgets, ie the version checking for updates and needing DNS but not having it and eventually timing out. The 8987 bug shows resolved, but did say that the issue is not resolvable at the time. Once I reconnected the coax, everything became stable again and no reboots on the modem or pfsense were needed. That is not what happened to me yesterday, I had to reboot both the modem and pfsense. Is this something I need to live with, not being able to check the status of my WAN via pfSense when my isp goes down? Is there a command line equivalent of this gateway status shown in the dashboard? [image: 1594595191411-screen-shot-2020-07-12-at-5.05.53-pm.png] Thanks, Jerold

I'm still unable to backup my config. Same issue from first post.

@anamuco247 Hi, Basically, USG and pfSense are different philosophies. (somewhere each is network security device, but on a different basis) so there is no way to migrate settings from USG to pfSense one at a time. You can, of course, keep the network topology, but first you learn how to use pfSense (test environment) and then configure it the way you need it. The starting point will be: https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf a little later: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

@zxjinn Thank you, my setup started working after matching the group name from pfSense with the group name on Synology. That was the missing part for me!

@Bipin Perhaps you could set up a policy where anyone caught sharing would be suspended. You can run WiFi scanner apps on a phone or tablet to see what SSIDs are visible. With WiFi Analyzer, there's even a signal strength meter, so that you can determine where a signal is coming from.

Awesome, thank you.

@sugi said in Chrome problem reaching my on premiss site in the same physical network: why only the chrome? I don't know what Chrome is ... / don't use Chrome.

You can move config files between factory and CE, that's not the issue. XML (config) sync will not work between different pfSense versions. Both 2.4.2p1 and 2.4.3 are very old you should upgrade both to current, 2.4.5p1. State sync will not work between nodes with disimilar NICs. You cannot have igb NICs in one and em NICs in the other. None of that should stop it booting. Where does it stop? Most likely is the manually edited xml is invalid. Steve

@ti-sangiogoadv Hi, I hope this is what you thought (it works for us): https://www.firewallhardware.it/en/pfsense-and-openvpn-timed-access-for-openvpn-and-limitations-on-the-lan/ +++edit: @ti-sangiogoadv "Good afternoon ladies and gentlemen." it's very cool

If it only appears at boot then, yes, it probably can be ignored. It looks like it's also associated with setting the QMA to CoDel which is not usually necessary. Leaving it as Taildrop with FQ-CoDel as the Scheduler should get the same results. Steve