Port restriction rule!
-
@johnpoz said in Port restriction rule!:
Can you put 3rd party firmware on it - ddwrt, openwrt, etc. All of these allow for setting a gateway on the lan interface.
You mean to put 192.168.10.1 in LAN gateway settings?But in this case would 192.168.20.0 subnet to see hard disk? And me use VPN on this gateway 192.168.20.1 for wireless network
-
@Antibiotic huh??
No you wouldn't put some other network as your gateway.. That setting looks correct.. If you can access its web gui and ssh via that 20.11 IP from your other network.. Then you fine - your problem with share access is most likely has mentioned by Steve - discovery doesn't work across subnets.. Just access the share via the IP 20.11 or use the fqdn you have setup that resolves to that 20.11 IP.
-
pfSense plus 24.11 on Topton mini PC
CPU: Intel N100
NIC: Intel i-226v 4 pcs
RAM : 16 GB DDR5
Disk: 128 GB NVMe
Brgds, Archi -
@johnpoz Do you mean connect by manually: \RTAX86UPro.home.arpa\HOME
-
Yes. Though entering the IP there should also work.
Check the firewall states when you try that. Is the client even trying to connect?
-
@Antibiotic fully qualified domain name.. ie what you posted from your AP its fqdn would be rtax86upro.home.arpa.. Be it that resolves on your network? You most likely would of had to have setup the record as a host override in unbound on pfsense or if your using some other dns for your network, etc.
edit
Try IP.. unless you had set it up in your dns, its possible that fqdn does not resolve.. If you ping it does it resolve to that 20.11 address? -
@stephenw10 Yea trying to connect \192.168.20.11\HOME but all time going error "the network patch was not found"
-
@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.
