Connect to remote clients
I'm trying to connect to a remote client that is connected with OpenVPN.
I am going to have this computer in a remote location and need to be able to connect to it.
My LAN is 192.168.34.0/24 and then the OpenVPN client has an OpenVPN IP of 10.101.1.2.
What do I need to do for me to be able to ping the openvpn client from the 192.168.34.0/24 network?
I have turned on the function that allows OpenVpn clients to route to each other. Otherwise, it's all the regular OpenVPN options for setup.
Assuming the pfSense which the client is connected to is your the default gateway in the LAN, you only need
- a firewall rule on LAN allowing the access to the client.
- a firewall rule on the client itself to allow the access from the remote site.
@viragomann Any way you could give an example of those rules? Would this be applied in the firewall or in the OpenVPN settings?
On pfSense you need only a rule on the LAN tab, as mentioned. The default rule allows any access to anywhere and will be sufficient, if you have it still in place.
However, I suspect it's rather the client, which will block the access from IPs out of its own subnet, as this is the default behavior. So you have to add a rule to it to permit the access you want.
I've 'instantiated my "OpenVPN" into an "OPENVPN" interface (using Interfaces > Interface Assignments ) :
These are the rules : it's a pass all :
Note : My OpenVPN is empty :
At this moment, my OpenVPN connected client can contact 'everything', locally, or elsewhere.
As already said above, a ping would work if the devic ethat you ping accepts ping (requests) - and not only from it's own LAN, but also from 'elsewhere', as my OPENVPN tunnel 192.168.3.0/24 is not my LAN.
Now : from a LAN client to the OPENVPN client : the LAN rules should permit this :
On my LAN interface, I have the default pass-all rules - "any source, any protocol any port".
And again, my OpenVPN connected client should accept and reply to incoming ping requests.
When my OpenVPN client (192.168.3.2) connects to my OpenVPN server (pfSense OpenVPN server 192.168.3.1) I can ping from my OpenVPN client an IP on my pfSense LAN (192.168.1.0/24 of course, as default values work fine) and the other way around.
Example : from my LAN client (192.168.1.16) to my OpenVPN client :
C:\Users\Gauche>ping 192.168.3.2 Envoi d’une requête 'Ping' 192.168.3.2 avec 32 octets de données : Réponse de 192.168.3.2 : octets=32 temps=303 ms TTL=63 Réponse de 192.168.3.2 : octets=32 temps=270 ms TTL=63 Réponse de 192.168.3.2 : octets=32 temps=193 ms TTL=63 Réponse de 192.168.3.2 : octets=32 temps=157 ms TTL=63
As I got it, the TO wants to access a remote client from the LAN, which might be a desktop machine like Windows. But by default an OS is blocking remote access by its own firewall.
@viragomann Right now I have a GLInet travel router that I'm trying to connect to (and the clients connected to it). It has a Luci admin configuration page.
@gertjan I have tried to instantiate the interface and apply the firewall rules, but now my VPN client gives me this error:
write UDPv4: Network unreachable (code=128)
Right now I have a GLInet travel router that I'm trying to connect to (and the clients connected to it)
That would be worth to mention. It's not obvious from your post.
So 10.101.1.2 is an IP behind the connected router? Then you will also need the correct routes on both sites for the respective other one.
Are the routes set properly?
As you wrote above, you want only to access 10.101.1.2. So this is the remote router itself.
For accessing the routers virtual IP there are no routes needed.
Does it respond to pings if you use the Ping tool on your pfSense with the default soure?
As mentioned already you need correct routing, and you would need correct rules in your openvpn interface on both ends.. Pretty sure it default to any any.
Another mistake common, is policy routing being done with would shove traffic out the wrong interface and not allow pfsense to send traffic out the vpn interface.
Another common issue is host firewall on where your trying to go, etc.