Update: Looks like this was caused by certain SNORT rules.
Disabling the SNORT interface and everything works again.
Will update further.

@steveits said in RAM Disk Settings - inconsistent limits:

I think that is related to this? https://redmine.pfsense.org/issues/13508

Thanks, yes, it does appear to be related, although my focus was on the inconsistent value reported by the GUI (before/after Save).

Since my first post, I've retested on 23.05-BETA built May 03 06:05:00 UTC, and it did appear to resolve the problem (the reported limit in the GUI was consistent before, and after successful and unsuccessful changes to the RAM Disk configuration). It also did let me change /var to 300.

But the redmine also reports that commit is to be reverted because of other issues. I guess I'll just wait for now.

@viragomann said in LAN Devices Not Accessing Internet through pfsense Firewall Behind 5G Router:

is only needed if you intend to allow connections from the internet.
Allowing inbound from private IPs on WAN is only needed if you there are other devices in the WAN subnet, which need to access pfSense or devices behind, or if you allow inbound traffic from the internet und you router nats it.
To investigate your issue, you should rule out a DNS

Thank you for your help and guidance on this issue. I was able to solve the problem by adjusting the DNS settings, and now the LAN devices can access the Internet without any issues.

@stephenw10 yeah its odd for sure - what I would do for testing and validation of the problem would be to duplicate dhcp and vlan without the modem.

Fire up something running dhcp and let pfsense pretend its a wan interface getting dhcp and run it through the switch with the same sort of setup. untagged towards your dhcp server/gateway for pfsense, and tagged towards pfsense..

You would use anything for the test, some laptop or pi would work just fine for such testing..

Yup, there was a bug introduced. The next snap will be fixed:
https://redmine.pfsense.org/issues/14351

Steve

@dgarner that rule to 50000 shows a state.. So pfsense sent on the traffic at least.

Here is what I always tell users having issues with port forwards - sniff!

So you can prove to yourself that pfsense is doing what it is suppose to do.. So you stop looking at pfsense as the problem.. Pfsense has one job here.. To pass on traffic to where your forwarding.. If it does that, its job is done.. And well yes return traffic.. But all of that can be seen with simple sniffing

Go to can you see me.. Send traffic to your port 50000, while you sniff - you see it hit your wan, then sniff on lan side where this 10.0.0.x address is.. Do you see pfsense send it on to that IP.. Does that IP send back an answer to pfsense? Is it a RST? Do you not see an answer?

If you do not see an answer - firewall on the host, or pfsense not the gateway. Or something wrong with proxy on that host.. If you see a RST back - then that host said to go away.. And there is nothing pfsense can do about any of those - other than maybe if you source nat the traffic to circumvent firewall on the host your sending traffic to by making it look like the traffic came from pfsense IP on that network - but that is not a good idea normally.

Replying here on an old thread because I had the same issue. I made an account here just to reply for anyone in the future.

In my setup, I have my standard gateway DHCP all disabled, passthrough to the pfsense.

There must have been an IPV6 conflict on the WAN side pfsense, because after I disabled the IPV6 DHCP on the WAN adapter, the issue went away.

@stephenw10 said in Strange Error with pfSctl:

Hmm, well if it's hitting SWAP that will slow everything down significantly.

Now after a few days the error didnt come back - RAM exhaustion and SWAP usage seams to be the culprit for that error. Hoping that the Memory leak in 2.6.0 is closed in 2.7.0 (Memory leak)

@techiemike said in Port forward not working for LAN:

if I use the diagnostics to test the port I get connection failed

If the service doesn't respond to a basic TCP test from the same subnet then it's probably something basic like the wrong bridge assigned on one of the interfaces in Proxmox.

Can pfSense even ping the internal host?

@stephenw10 Thank you I will have a look at it

@jonathanlee
Thank you. I did not know that Suricata can be configured to block Nmap attacks. The image you provided is very helpful. Crackers are said to "taste" the target router,

and when they attack the same target again (the victim notices an anomaly and resets the entire network), they use Nmap to investigate the manufacturer and model of the router. If such a thing happens, knowing whether the attacker came to "taste" with Nmap could be a clue to record the attacker's footsteps.

If you're able to I would check the packet counters on each tunnel. That does mean other traffic not using it which may not be possible.

I would bet this is a missing P2 though. Can we see what you have configured?

The local private subnet is usually just to access the modem for diagnostics and it's usually only available when the upstream cable connection has lost sync. I wouldn't expect it to appear on a normal connection.
However you can stop pfSense pulling a lease from the local server by adding it's IP to the Reject leases from field in the DHCP client config on WAN. So it's probably 192.168.100.1 or 192.168.100.254.

Steve

@stephenw10 I re-followed provided wiki and got it working. One thing I had trouble with, all of the sudden was my Wiregard road warrior user setup stopped providing route. Fixed it by pfsense reboot.

Thank you for your help!!!

@stephenw10 Thanks for the hint, I've installed the package, applied the recommended patches and rebooted. I'll watch ;-)

@jbob said in Random Website Outages?:

@stephenw10
OH FOUND IT. Snort had picked up the IP as suspicious and blocked it. Now just need to figure out how to add an FQDN to the snort pass list

Create a FQDN alias under FIREWALL > ALIASES in the pfSense menu. Then either create a new Pass List (or edit any existing one already assigned to the interface) and add the FQDN alias to the Pass List. When editing a Pass List, there are controls at the bottom of the page for adding, editing, or deleting IP addresses, networks, and host or network aliases.

Once the Pass List has been edited to include the FQDN alias, go edit the Snort interface and assign the Pass List using the drop-down selector for Pass List. Save the change and then restart Snort on the interface so that the binary daemon will see the change.

Note that FQDN aliases are resolved only once every 5 minutes. A host or domain that changes addresses more frequently than that may not be reliably resolved. Also, if the host or domain in question is part of a CDN (content delivery network), then the IP address will likely change too often to be effectively resolved for use in the Pass List.

Here is a post I created back a couple of years ago when the FQDN feature was added. There are some screenshots in the post of the feature in action, and from those you can also see how to configure them in a Pass List.

https://forum.netgate.com/topic/160771/new-often-requested-snort-feature-coming-soon

@hoandco

Final SLD with all devices connected
93fcb284-0676-4063-a735-e2d7c4a1585c-image.png

Hmm, but OPT1 always does?

In 2.6?

It's a miracle! 😁