Port restriction rule!

[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."

[Antibiotic]

@stephenw10 Than how to do this ?

[johnpoz]

@Antibiotic said in Port restriction rule!:

depending on the clients."

Is the important part here.. If the dot client is sane, it wouldn't work - but sure guess there are some really shitty dot clients that don't actually validate..

Either way it helps with dot circumvent, because it the bad client will just work anyway, ie be redirect, or it will fail. I was just trying to point out that redirection of dot shouldn't work.

Dot is the less common use for clients, android might do dot vs doh? Dot is easy to block, just don't allow 853.. Doh is harder to block because it hides itself with all your other 443 traffic that has to be allowed for the internet to actually work.

Dot is more suited for NS that is forwarding to some other NS, and not actually the end client.

[stephenw10]

Do not use discovery. Enter the IP addresss or hostname directly.

[Antibiotic]

@johnpoz I delete this rules regarding DOT and did by instructions in Blocking External Client DNS Queries regarding DOT)))

[johnpoz]

@stephenw10 I am still wondering how your quote ended up in Russian ;)

[Antibiotic]

@johnpoz Sorry not understand completely what you mean, but its OK because Russia come back to the global honest WORLD))) not a rules-based order

[johnpoz]

@Antibiotic Steve's post was clearly in english, but then when you quoted it Russian ;) I was not aware that the forum software translated quotes to the posters language or whatever.. So clearly there was some copy paste on your part?

edit:
Your dot rule to lan subnets makes no sense.. Because you have a rule above it that allows any from lan to assume any local used network. So 853 would be allowed by that rule, there is no reason to allow 853 specifically. to lan subnets.

On a bit of side note, what is the point of * as source... How would there be any source ingress into this interface unless it was the subnet this interface is attached too?

The only time any for source makes any sense is if the interface is a transit network. The source IP should either be specific for IPs on this network that you want to have different rules for, or it should be set to the subnet the interface is attached to.

[stephenw10]

A browser plugin would do that. Or just Chrome with translate turned on.

[Antibiotic]

@stephenw10 I tried but do something incorrectly

Wireless router IP 192.168.20.11 and set

do \192.168.20.11\HOME but error connection