@stephenw10 said in [Solved] Ooma not working: You shouldn't need any of those ports forwards. Exactly - says right on their site, these are "outbound" ports https://support.ooma.com/home/advanced-connections-and-service-ports/ [image: 1581775000360-outbound.jpg]

If you saw that limit between two hosts in the same subnet that traffic goes directly, or at least it should. pfSense never sees it and cannot do anything to affect it. I would have to guess something is misconfigured on the client. Steve

Hard to give any specific advice without knowing exactly how it's setup. But in general... Try to access the webgui from another device then: Check the firewall logs for blocked traffic from the test client. Check the state table in Diag > States for open states from the test client to pfSense on port 80 (asssuming you're using http still). Run a packet capture on the internal interface the test client is connected to. Filter by the test client IP and port 80. Is that traffic even arriving at pfSense. Steve

Back then it might have been wiped out automatically. The error was from two days ago in your screenshot, though. I'd still say it was a failed attempt to change a setting to something with an international character. No matter what, though, the best path forward is to upgrade.

Check the firewall logs for blocked traffic. I could imagine it's trying to open a different port perhaps and has to timeout. Otherwise it's hard to see what pfSense could be doing there. You are fowarding ports to it I assume? 80 and 443? Steve

Yes. I was thinking that they might be able to help getting me off those spam lists since it is their IP block. But now that I think about it, talking to ATT is probably a waste of time. At a minimum they will tell me to use sbcglobal. My email ISP has tried to help with spf and that worked for several years but it's apparent that is no longer good enough. This is the handwriting on the wall for me. I'll have to pull the plug on my old address and wait out the blacklisters.

@JKnott I did, see past reply's. I will not know till and if it happens again.

@hilltop79 Can you login via SSH and run: systat -vmstat Then check the interrupts and if the load is high. If that's the case, switching to polling could help. Cu

I had a large Net limit rule in firewall, ive deleted it, but i wasnt using it for anything Thank you for your time steve

It doesn't matter if you changed your mind after switching to it, the changes were set at that point. If you change it back to stable, you'll have to at least manually reinstall pkg, which is probably what you already did by following that link.

@inagan Well if you're accessing via your browser, it could be your browser.

I just pushed a fix for that syntax error, new versions of the package should be available shortly.

I found the Problem: At the proxmox hosting platform, there was an option, to pass the traffic through the Host firewall (what was disabled). Therefore - pfsense has done everything right. After disabling this flag everything works like expected. THX for your support!!! Bfo

Hmm, OK well you need more RAM or less stuff using it. You can certainly tune Snort and Squid to use less. There are a number of threads about both. Steve

unbound-checkconf is grabbing a big chunk of memory. It should exit before starting unbound. When did you reboot last ? What's the size of unbound.conf. Did you inspect System and Resolver log ? PfblockerNG.log ? If you stop unbound, is the unbound-checkconf process still present.

IPSec is generally faster so if you have Gigabit at both sites you will be able to use more of it with IPSec. You can use either though. https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-example-configuration-shared-key.html https://docs.netgate.com/pfsense/en/latest/book/ipsec/site-to-site.html Steve

It's been while since I tried it but I think you had to deploy it as a profile to OSX to use anything but the default options there. However since that hangout was made I also think OSX may have stepped up the encryption levels it uses by default... so maybe a bit of both in play here. I know at the time we chose those settings as the only thing that would work with everything. Try setting it to the values in the hangout to make sure it connects and it is a encryption settings issue. If so look at deploying via a profile. Steve

You might be able to do this by making use of the option: Skip rules when gateway is down. That's a setting in System > Advanced > Misc. It applies globally so you would have to be careful. With that set use two rules on the LAN to pass traffic. The first via the main gateway. The second via the LTE gateway with limiters set. If the main gateway goes down that rule will not be applied and traffic will hit the second rule. Add copious notes because that would be an unusual setup, highly likely to confuse anyone who sees it later. Steve