@Bob-Dig yeah lol, but I'm pretty sure I've followed everything to the letter as the other services are working or it's something small I'm overlooking....

@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.

@Bob-Dig thanks for your feedback again!

Yeah, I think they are assigned properly, unless I'm missing something here and PPPoE actually requires a different assignment.

assigments.png

gateways.png

Thank you!

@Shan-lapierre said in Monitor NAT rules:

And infact my NAT rule was created whit "Pass" flag and pf doesn't created any fw rule.

I'm still looking for a usage of that "Pass" case ^^

Normally, a NAT rule translates traffic coming (initiated) somewhere on 'the WAN' (the Internet) and the address (WAN IP) (and port) has to be mapped == translated (a,d port) to a LAN addresses, so it can reach this device.
This needs of course a WAN 'firewall' rules, as by default nothing can enter the WAN - everything is blocked by default.
A NAT rule without an accompanying firewall rule .... won't work, as traffic will never reach the NAT rule, as traffic can not enter into the WAN interface.

I'm not saying other types of NAT exit, they do.

From what I've read :

receive traffic to my firewall on a specific port from a specific public IP.

Everything is working (so the external traffic reaches me on an endpoint inside my network that is listening on that specific port).

your use the classic method, and you need a auto generated firewall rule on the WAN interface.

@ASGR71 putting a block rule to 53 just below the rule you allow 53 to pfsense IP would be a valid solution if you want to block clients on that network from talking to any normal dns on the internet.

If you are having issues with clients using dns other than pfsense. While that rule would block normal dns, it doesn't prevent clients from using doh (dns over https) or dot (dns over tls).. while dot should be easy to prevent since the standard part is 853.. And clients don't normally use dot. A forwarder would use dot to forward to some other resolver via tls.

Blocking clients from using their own dns to circumvent local dns has become an uphill battle.. Browsers deciding to use doh on their own without explicit opt-in by the user is a problem.

Blocking doh is becoming a challenge. Since it uses standard 443 port of https traffic - which is pretty much everything on the internet these days. Blocking this has come down to using lists of known doh servers and blocking the IPs.. Which can turn into a wack-a-mole game..

But if you just want to prevent some client talking to say 8.8.8.8 or quad9 or 1.1.1.1 on 53, etc.. then yeah that 2nd rule accomplishes that.

@steveits said in Geoblocking the world except for home:

@nogbadthebad Since you showed "alias permit" just be aware that reportedly de-dupes across other permit or deny lists. There was a thread last year sometime where someone pointed out IPs were being removed. Alias Native will leave the lists unchanged.

Cheers I've changed them :)

@akinori said in Allow traffic:

going to let traffic coming from LAN interface going out to WAN and vice versa?

By default pfSense will pass all traffic out and in on the LAN interface. WAN blocks all inbound traffic by default and will allow all outbound traffic without any special rules.

@tbr281 said in Block redirect:

Just wish it would redirect it.

Even "dirty websites" use TLS these days. Easy to recognize, their URL starts with https://

Without drastic measure on your LAN, that is, all your web visiting devices and pfSense, you can't redirect https://"dirty websites" to https://DuckDuckGo
Your browser won't allow this.
The test : is the host name "dirty websites" present in the certificate obtained ? will fail.
Have a look :

e2e336b4-a7bf-4b88-ab68-5e617416ed3b-image.png

That's doesn't look like "dirty websites" : your browser will refuse the connection.

If it was possible, you would also be able to redirect https://some-bank-acess-you-use to https://some-bank-access-you-use, and because you control some-bank-access-you-use (and your site looks identical to some-bank-acess-you-use), now you get the access credentials.
And five minutes later you can access https://some-bank-acess-you-use with the credentials you've obtained, and do what you want.
The thing is, why would you ask if something if possible if you don't want it to be possible ?
After all, https://"dirty websites", or https://facebook.com or https://some-bank-acess-you-use or https://some-bank-acess-you-use, for your PC, switch, pfsense, upstream routers of your ISP etc, its all the same : a connection to some server over port 443, TCP.

@modesty said in How to open UDP port 1883 to IoT Cayenne my devices:

My IoT device is connected to my LAN (WiFi) to 192.168.0.52 (static) and is sending packets to my Cayenne dashboard.

So allow the packets to the dashboard IP instead of the pfSense interface IP. At destination select single host and enter the dashboard IP.

@alexhen
You cannot schedule NAT rules.

You have scheduled the associated firewall rules though, but even if these rules are disabled, the NAT rules are still active and do what they meant to do and the first one wins.

Not really sure what to try to achieve with this idea. If you just have two internal servers listening on port 80 set up HAproxy. Doing so you can also let HAproxy do the lets encrypt stuff.
Also you can run a proxy on one of the backends themself.

@atxcoder you need a Web Application Firewall (WAF) to do that, pfsense FW rules block at the ip layer. x-real-ip is application layer. The traffic is allowed because it came from 10.0.10.4.

pfBlockerNG and the ASN numbers, PfblockerNG will also import JSON but you can't create create a single alias with IPv4 & IPv6.

Screenshot 2022-09-14 at 08.41.28.png

https://db-ip.com/as15169-google-llc

@adminproconer said in Firewall rule problems. (Client-to-client forward):

Where should I start troubleshooting the issue?

With the network settings and firewall config of the concerned device.

Ensure that all devices in both subnets use pfSense as gateway.

If you can access a device from within it's own subnet, but not from another network segment check its firewall and ensure that it allows access from outside.

Note: simply changing the terminal settings to send ^H instead of BKSP is not a universal fix.

For example, when I did this (iTerm2) I noticed that when ssh'ing to a new host and getting the prompt to accept/reject host keys, I can no longer backspace properly. Instead of deleting, it prints the literal ^H

32683b3b-8f19-4633-a540-f7628ecb76f9-image.png

@cool_corona said in killing existing (specific) fw states when rule change from disabled to enable:

d the dropdown in "schedule" is empty (always none).

So, what I'm looking for is that exactly not what I'm looking for :)

As mentioned, what I'm looking for is the ability to run a specific task when a rule is enabled or disabled. Not a schedule !

I you want a schedule, go under firewall-> schedule, create your schedule and then go back where you took your screenshot from and assign that schedule :)

Your post is not entirely clear. Perhaps it is a language translation issue ???

Are you saying that now your pfSense box is behind some kind of double-NAT? You must eventually have a public IP in order to route traffic (not an RFC 1918 address). However, if your pfSense box now communicates with some upstream host that in turn provides a NAT to some type of public routable IP, then your Snort rules update should still work.

I assume other Internet traffic through the pfSense box works?? Or do you really mean to say you have isolated this pfSense box from the Internet? If that is the case, then there is no method for an offline update in the Snort package. It requires Internet access to update its rules.

@quasaur So you mean having a single supernet broadcast domain with e.g /22 mask and have many / 24 "subnets" with a /22 mask and single gateway?
If yes, it can be done, BUT the issue would be tha you need to manage all mac addresses manually.
It can be done but it is very cumbersome, especially in the long run.
You are better off segmenting your lans with vlans and use single dhcp on pf to manage them all.
You cant have rules between them as long as they are on the same physical interface too

@sub2010
I use the same config. domain.tld and matrix.domain.tld. I'm not sure about your srv record, I dont use one.

For my certificate I use 1 certificate. In acme you can specify multiple domains for one certificate. Mine includes. *.domain.tld and domain.tld

Get a cert like that, put it on your haproxy frontend and also put it on your matrix host and point your homeserver.yaml to it and restart matrix. The error is still saying your cert is expired, so I am assuming the cert you have on your matrix host that your homeserver.yaml is pointing to is expired.

@leonroy said in Can't create IPv4+IPv6 Firewall rule with an alias:

What I ended up doing was sticking my PiHole IP address in an Alias as well and setting that as the Source alias. Not sure if that's the best way of doing it but it worked...

If your PiHole should answer IPv6 and work with IPv6 it needs an IPv6 address. Without that makes no sense, then you can simply block all IPv6 alltogether. If your Pi has IPv4 and IPv6 then that's the right way, put both into the alias and use it in rules.

That said I wouldn't work with invert rules but that's my approach.

@jimp said in Support for IPv6 firewall entries with dynamic delegated prefix and static host address:

While some people choose to only allow specific source hosts to specific destination hosts in a DB net, usually people don't get that fine-grained, either because the sources need to reach most if not all the resources in the target network, or because there aren't that many to bother with being that specific. Either way if someone has to get that complex with rules it's highly unusual for them to be using any kind of dynamic addressing like prefix delegation.

Now that I can completely agree with! But may I suggest that you name the feature in another way? As this works with and without prefix delegation, and is more concerned about using a shortform (host part only) on interfaces.

This is based on that I only understood the limit, when I read the sourcefile, and realized it did not use my PD, but the network the interface was assigned even if it was static.