Port restriction rule!

[johnpoz]

@Antibiotic what example is there to show.. Out of the box the pfsense wan rules don't allow anything inbound to your pfsense wan IP from the internet.

What is "exposed" to the internet is what you add.. Here are my wan rules currently

This is what I have exposed to the internet... Ie some rando IP address out on the internet can talk to these ports.. The ones that are in the US, or elsewhere via my pfblocker alias of what is allowed to talk to these ports. Mostly US based IPs

I have those block rules at the end that log, because I have turned off logging for the default deny.. And this logs what I am interested in seeing. Only tcp syn traffic to my wan, and some common udp ports that might be interesting to know if seeing traffic to those ports..

Here are my LAN rules.

My clients could talk outbound on BGP... Oh no ;) hehehe

Out of the box the only rules are wan are the 2 blocking source IP of rfc1918 and bogon.. Nothing is "exposed"

[Antibiotic]

@johnpoz Do you have openvpn server or client?

[Antibiotic]

@johnpoz said in Port restriction rule!:

what example is there to show.. Out of the box the pfsense wan rules don't allow anything inbound to your pfsense wan IP from the internet.

Inbound yes, but outbound allow all like me undesrtanding?

[johnpoz]

@Antibiotic that is for my server, so I can connect while out and about. I also have a vpn client setup on pfsense that talks to one of my vpses out on the internet. But I don't normally use it.. It is there for testing/helping users with client setups.

I have two instances running, one on 443 tcp (this is for when udp 1194 might be blocked outbound where I am at).. And then your common UDP 1194 instance.

And yes I allow all outbound.. I have no reason to limit what my machines can talk too.. They are my machines and under my control, they only ever run code that I trust.. Blocking outbound would be too little and too late if I infected myself..

And then again, if I did infect myself - highly unlikely they would be using some odd ball port to talk outbound, they would use 443 most likely, just like everything else on the planet uses now.

Now I do log all my devices dns queries (I use pihole - mostly because I like its eye candy more than pfblocker).. And I do check on this now and then to see if they are talking to anything that looks weird.. But I don't block them from talking outbound.

[Antibiotic]

@johnpoz How do you connect pi hole and any additional rules in pfsense?Why I'm asking because have also small Glinet router with built in adguard dns server and he is dusting on sofa. Could be also start using in this way!

[johnpoz]

@Antibiotic I point my clients to the pihole, which forwards to pfsense, which then unbound resolves. There are no rules needed on pfsense do this.. Pihole is just like any other client asking unbound for dns.

[Antibiotic]

@johnpoz said in Port restriction rule!:

I point my clients to the pihole

How? Did you manually set pihole ip address for each home network in dns settings?

[Antibiotic]

@johnpoz said in Port restriction rule!:

which forwards to pfsense

Did you set to forward pihole dns request to unbound than?

[johnpoz]

@Antibiotic yes my pihole is on 192.168.3.10, it forwards to pfsense IP address 192.168.3.253

Pfsense manages my local network home.arpa, and all the dhcp for all my network.. You could have pihole handle that if you wanted.. But if you have more than network that can get a bit complicated.

client ask pihole for say nas.home.arpa, it says well that is not on any of my block lists so like anything else you ask for it forwards to pfsense.. pfsense says nas.home.arpa is at 192.168.9.10

One thing you prob want to do is in pihole allow it to forward ptrs for rfc1918. So you would uncheck this

And you sure don't want it do dnssec, because unbound is doing that.

pfblocker can for sure do the same thing, etc. but I like the pihole eyecandy

Its easy to look at the query log, filter exactly on what a machine asked for - or anything specific has been asked for, and who asked for it.

[Antibiotic]

@johnpozHello,

Local subnet 192.168.10.1
Local subnet 192.168.20.1 (connected router in AP mode, this router have usb connected hard disk with sharing files)
How to make to see PC connected to 192.168.10.1 subnet to see this hard disk for file sharing?

[johnpoz]

@Antibiotic not sure what is what here, but your policy routing.. If you want network x to access something on y you need to allow it before you policy route out some specific gateway.

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing

[Antibiotic]

@johnpoz I did

But this rule should be on top, regarding DNS redirect and all other redirection rules or can be locate above "Default allow LAN to any rule"?

[stephenw10]

That's fine as long as you only need TCP traffic between the local subnets.

Define exactly how you are testing? If by 'see' the hard disk you mean some sort of Windows device discovery that usually only works within one subnet.

[Antibiotic]

@stephenw10 said in Port restriction rule!:

Определите, как именно вы проводите тестирование? Если под словом «видеть» жесткий диск, вы имеете в виду некое обнаружение устройств Windows, которое обычно работает только в пределах одной подсети.

Yes exactly, i want to connect from Windows pc subnet 192.168.10.1 to Wireless router hard disk in subnet 192.168.20.1

[Antibiotic]

@stephenw10 Oh i did mistake with only TCP and change to any)))

[Antibiotic]

@stephenw10 But the rules order are correct, regarding the rest redirection rules? Will they work correctly?

[Antibiotic]

@stephenw10 Now can connect to Wireless router web gui form PC in other local subnet but still not able to see this hard disk on router connect over USB like samba sharing? Network discovery is ON for private network.

[johnpoz]

@Antibiotic how and the hell did Steve's quote turn into Russian? ;)

I didn't look that deep at you rules - but that DOT redirect, ie dns over tls more than likely will not work.. Even if you have unbound listening for dot. Because any sane dot client should validate the cert is correct for the NS they are wanting to talk to via dot.

Say your client is trying to talk to the quad9 via dot, it should validate that the cert is valid for dns.quad9.net, if not it should complain and not actually work. Unless you were using a cert it trusts that has cn/san for dns.quad9.net.. If it doesn't its a lame dot client, because one of the main features of dot or doh is validation that your talking to the NS you think your talking too via cert being correct and signed by CA you trust.

[stephenw10]

@Antibiotic said in Port restriction rule!:

not able to see this hard disk on router connect over USB like samba sharing? Network discovery is ON

Device discovery like that typically only works inside the subnet of the device doing the discovery. So it will not 'discover' something in a different subnet.

[Antibiotic]

@johnpoz I did how to recommend NetGate doc in DNS redirect section: "Clients using DNS over TLS or DNS over HTTPS could circumvent this protection. Redirecting or blocking port 853 may help with DNS over TLS, depending on the clients."