Port restriction rule!
-
@Antibiotic well its not just one \ it would be two \
Don't use the specific share.. Just see if you can access to list all shares.
-
@johnpoz i TRIED FROM PC SUBNET 192.168.10.1
net view \rtax86upro.home.arpa and get "System error 53 has occured, the network patch was not found"
-
@johnpoz said in Port restriction rule!:
well its not just one \ it would be two \
i have put two all time but appear on forum only one)))
-
Unless you know that FQDN resolves I'd test with the IP directly:
\\192.168.20.11 -
@stephenw10 Already tried FQDN and by IP all time error. I don't know what the wrong. Can ping. can access web gui and SSH, horrible Windows)))
-
@Antibiotic sure not a firewall issue on the AP thingy? Maybe it doesn't like sharing to non local IPs?
Or what are your firewall rules on the interface on pfsense where your client is trying to access this 20.11 IP.. maybe your not allowing the smb port, which I would assume would be 445. unless its some really old smb sharing maybe using port 139.
-
@Antibiotic said in Port restriction rule!:
"System error 53 has occured, the network patch was not found"
Still that exact same error?
It would be surprising to me if the AP allows gui access and ssh but not smb. Especially because in a 3rd party firmware like that those issues are usually discovered and fixed.
Feels to me more like the client isn't even trying to connect. Hence why I suggested checking the pfSense states when you test. You should see the port 445 states opened on both interfaces.
-
@johnpoz Can this to be resolve if set pfSense interface for AP router not to 192.168.20.1/24 but 192.168.20.0/16 or 192.168.0.0/16
-
No. That would create a subnet conflict with 192.168.10.X.
-
@stephenw10 Ah ok , will search by internet how to resolve this problem
-
@Antibiotic what exactly are you going to search for.. Per Steves suggestion, I would validate traffic is going to 20.11 when you try and open your share.
You should see your syn being sent, you can easy check via the states table. But you can also just sniff.
When you try and open your share you should see the syn, and syn,ack back.. If you see the syn but no syn,ack then either that thing is not listening on the port your trying to open up to it, or its not sending it back to pfsense or it has a firewall that says hey not going to send this traffic up the stack to the application.
-
@johnpoz said in Port restriction rule!:
You should see your syn being sent, you can easy check via the states table. But you can also just sniff
If you mean to check here
I dont see any to port 445
-
So 3 possibilities:
The client is not even trying to open a connection.
The firewall is blocking the connection.
The client is not using port 445A packet capture on the client interface would confirm it.
But I'm going to guess the client isn't even trying. That 'network path' error makes it seem like it's trying to connect directly.
-
@stephenw10 Under client name , do you mean Host pc on subnet 192.168.10.1?
-
@stephenw10 Have kaspersky firewall rules
-
Try disabling that local firewall entirely as a test.
-
@stephenw10
Disabled, all the same -
Check if it's opening any states.
Check in a pcap if it's even sending anything.
Try a different client.
-
@johnpoz I have read in official statement that MULLVAD block port 25. Because of a Microsoft security issue, we also block ports 137, 138, 139, and 445. Could be this a cause of provlem with sharing?Local subnet 192.168.20.1 using MullvadVPN
-
@Antibiotic most internet providers block those ports.. Those would not run over the internet no.. Your vpn client you have setup on pfsense would have zero to do with you talking to some client on another one of your networks..
Your not policy routing out your vpn are you.. That would prevent you from talking to other devices on other networks/vlans.. ping shouldn't work either..
What are you rules on the client side interface on pfsense? The rules on the server side, where your file shares are mean nothing in accessing something on that network from the client. Do you have rules in floating forcing traffic out a vpn connection?
When you policy route, and you want to access stuff on your other networks you need to make sure you setup a bypass to allow what you want.
https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing
Have you done the 30 second sniff to validate traffic is going to your share?? It really is like 30 seconds to validate this.. Have you looked in your state table?
