OpenVPN connecting fine, but only http or ping
-
I have OpenVPN setup on my pfSense (2.4.2) Netgate box. Clients connect fine, and can ping both the pfSense box and a laptop I have attached to the LAN port on the pfSense box, but SMB and RDP fail.
Oddly enough, It all works in from the laptop on the LAN port to the remote OpenVPN client that's connected.I get this using TUN or TAP (both connect fine, then ping but not SMB or RDP.
I used the OpenVPN 'wizard' originally to configure the server, so I have an any/any rule for OpenVPN
I would post the openvpn log (status/system logs/openvpn) but it seems 'stuck' I have the same last line no matter how often I disconnect/reconnect.
I have rebooted pfSense, and disconnected/reconnected the client a couple of times - and no change in the log.Any ideas? Would a log help, even though it is not updating?
-
Are you certain it's the firewall stopping it? SMB and RDP may be locked down on the target system with a local firewall.
-
There are several things that could be happening here, but my guess is… you're trying to use hostnames to connect to your resources over the VPN, which isn't going to work without exporting DNS or enabling NetBIOS over TCP/IP and configuring a WINS server.
All of your connections will need to be made via IP unless you implement one of the options above.
-
All of your connections will need to be made via IP unless you implement one of the options above.
Are there any connections over anything other than IP these days? The old NetBIOS/NetBEUI networks are long obsolete, with even Windows file sharing working over IP. If he can reach a destination over http or ping, but not another protocol, then it's not a DNS issue. However, he might not be able to browse Windows shares, as the broadcasts/mulitcasts will not likely be passed over the VPN.
-
All of your connections will need to be made via IP unless you implement one of the options above.
Are there any connections over anything other than IP these days? The old NetBIOS/NetBEUI networks are long obsolete, with even Windows file sharing working over IP. If he can reach a destination over http or ping, but not another protocol, then it's not a DNS issue. However, he might not be able to browse Windows shares, as the broadcasts/mulitcasts will not likely be passed over the VPN.
Of course it's an IP network, that's not what I meant. My comment was suggesting that he's probably trying to connect to his shares via hostname instead of IP….e.g. \fileserver vs \10.0.0.30, which doesn't work over VPN without one of the solutions I mentioned.
Also, the OP never mentioned accessing his resources via HTTP, so it's important not to make assumptions. If he's trying to access his resources via hostname, it very well can be a DNS issue because his queries will fail unless a solution is implemented that resolves hostnames for the remote network.
However, he might not be able to browse Windows shares, as the broadcasts/mulitcasts will not likely be passed over the VPN.
The only requirement for Windows file sharing currently is port 445 (TCP), so he very well can browse file shares, but he will have to address name resolution if trying to connect to the server via hostname.
Also, saying "broadcasts/mulitcasts will not likely be passed over the VPN." suggests that there may be a chance that they will which is false. Broadcasts will NOT traverse the VPN unless a bridged solution is implemented.
-
^^^^
Once again. If he can ping or use HTTP via host name, it's not a DNS issue. There are not different DNSs for different protocols. A DNS maps a host name to IP, no matter what protocol it's going to be used for.I recall reading about NetBIOS name resolution, about 20 years ago, when I was at IBM. There were, IIRC, four methods for resolving a NetBIOS name to IP address. These were WINS, DNS, /etc/hosts and LMHosts. Unless they're using different names for NetBIOS vs everything else, normal DNS will work fine. In fact, given that IP is used for everything, I don't see how relying solely on DNS would fail, if it works for other protocols.
Prior to IP, NetBIOS was essentially placed in an Ethernet (802.2/802.3) or other frame (we had Token Ring at IBM) and sent out without using a routed protocol, though NetBIOS/IPX may have been used back then.
-
If he can ping or use HTTP via host name, it's not a DNS issue.
You may have meant to say something else, but this statement as written is not entirely accurate. Pings are used to verify basic IP communication between endpoints, however, pings by themselves can't prove or disprove a DNS issue.
There are not different DNSs for different protocols.
Agreed. I never said there was. My apologies if my words left room for that interpretation.
A DNS maps a host name to IP, no matter what protocol it's going to be used for.
Agreed. Which is why the OP needs to clarify how he's accessing his resources, so we can advise him according. If he's accessing his shares or trying to RDP via hostnames, the DNS queries will fail because there are no A records for his hostnames when he's away from his LAN. Trying to connect to something via hostname will always fail without proper name resolution of some sort… that was my point.
Connecting to a share on his LAN via \fileserver works because of local DNS resolution. Without implementing a way to resolve hostnames on a remote network, connecting to \fileserver over VPN will always fail because the client's DNS server neither has the proper forward lookup zones nor the A records for the hostnames he's trying to connect to.
I recall reading about NetBIOS name resolution, about 20 years ago, when I was at IBM. There were, IIRC, four methods for resolving a NetBIOS name to IP address. These were WINS, DNS, /etc/hosts and LMHosts. Unless they're using different names for NetBIOS vs everything else, normal DNS will work fine. In fact, given that IP is used for everything, I don't see how relying solely on DNS would fail, if it works for other protocols.
Yes, DNS will work for everything if the correct server is pushed to the client, otherwise, he has no name resolution for the hostnames/domain on his LAN.
OP, basically we need more information in order to offer more targeted troubleshooting. How are you accessing your resources? If it's via hostname, you will need to address name resolution over the VPN. Since you've already stated that you can ping all your devices over the VPN, if you are entering IP's to connect to your resources then you need to start looking at your firewall rules on PFsense, the software firewall on the servers themselves and then verify the services you expect to be running on the server are actually running and listening on the ports/protocols you expect.
-
You may have meant to say something else, but this statement as written is not entirely accurate. Pings are used to verify basic IP communication between endpoints, however, pings by themselves can't prove or disprove a DNS issue.
I said if you can ping via host name. That implies DNS is working. Otherwise you couldn't ping by host name.