#2 there sounds like the expected behaviour with the CSRF check. That has been present for a long time but it was not obvious what was happening. In 2.4.5 a custom page was added that provides feedback: https://redmine.pfsense.org/issues/9799 #1 Obviously should not happen. It can take a lot longer to complete tasks if the firewall has no WAN connection and is trying to use one, such as if you have ACB configured. I've never seen it take 15mins just to complete the wizard though. #3 Is it possible you are doing that before completing or escaping the initial setup wizard? Steve

No, I don't believe that's possible. If the user has sufficient privileges to access vtysh they will be able to access pfSense. At least using the built in user priviledge management. I guess I could imagine a user who's default shell spawned vtysh.... It would probably be relatively easy to escape though. Steve

That should work fine. I'm not sure if I've seen that specific switch but LACP to Microtik is quite common. What about if you assign the lagg port dircetly? Can you pass traffic without the VLAN? Steve

@StarsAndBars said in Buffer Bloat Mitigation w/o speed impact?: @chpalmer Thanks for your response. The Cable Modem provided by the ISP is a Hitronic CGNM-2250 and as it is a business-class account, I do not have the luxury of selecting my own. Since this is a Puma6 model modem keep in mind that it has some issues.. http://badmodems.com/ Make sure you have no UDP traffic going on while you are testing.. Some modems have various patches in place but depending on the ISP some do not.. UDP traffic can be quite the problem for these modems to handle.. VOIP, video, gaming ect.. If you are a Comcast customer then the only reason they will not let you use your own modem as a commercial customer is if you have purchased static IP's from them. Otherwise we do it all the time. I would bring up the Badmodems site to your ISP and see if they will give you another Broadcom based model..

Thank you! 'State Killing on Gateway Failure' was set and did not need to be. I'll have to wait for the next time the VPN goes down to be sure it solves my issue, but it looks like it should.

Yes, more information required. Are you replacing the Microtik device with pfSense? What is the WAN connection type? Steve

Hey everyone. So. I've managed to get everything working. I am using TalkTalk Faster Fiber This is my setup now: TalkTalk ISP wall box -> RJ11 Draytek Vigor 130 Modem Had to log onto it and manually configue it to be in Bridge mode) -> RJ45 pfSense SG1100 IPv4 and IPv6 configured as DHCP I hope in the future this will help people who had the same questions I did! Cheers

@Raffi_ said in Losing WAN connection intermittently: A can of compressed air held upside down does the same thing. óóóó, the blessed physics and the expanding gases

ok thanks i will just leave it. cheers for the advice.

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