Unable to access LAN machines over OpenVPN
-
Here are the firewall rules. I had it add the one for openvpn from the wizard.
-
Also, here are the OpenVPN settings I am using. I tried with and without the option to "Allow communication between clients connected to this server" and it didn't seem to make a difference. Also, I tried connecting my LAN machine to the VPN, and even when both were on VPN they couldn't see each other.
-
The first oddity I noticed is that you are using port 443 for you OpenVPN server on pfSense. Normally this would default to 1194 although you can change it to another port if you wish. Using 443 is likely to cause some confusion for your PC as this is the standard HTTPS port.
"Allow communication between clients connected to this server" is for devices on the Outside of your network (two laptops in a coffee shop connecting to your home LAN able to see each other). It doesn't sound like you need this, as your gaming machine is at home on the local LAN and your remote machine comes in through OpenVPN.
In another thread, I did post a little primer for setting up a RoadWarrior VPN, which I think you are close to in your setup: https://forum.pfsense.org/index.php?topic=76763.msg418769#msg418769 It might help out a little.
-
Thanks! I'll be home soon and I'll give a look through that. The reason I'm using 443 is because where I work I am behind a firewall that only allows 80 and 443 out.
-
So I looked through that and that's configured pretty much the same way the video showed, and the way I have it set up. Does anyone have a non-pfsense suggestion even? I've been using pfsense for 2 years and this is the only problem I've never been able to get past. Having spent the last 4 days on it I'm losing my mind lol.
-
under Advanced did you push a route to your LAN? Like:My mistake - long day. You don't need that. I have something like it to get to my DMZ from the tunnel.
[s]push "route 192.168.1.0 255.255.255.0"[/s]Are are you on the same subnet at work as you are on your LAN at home?
Try to avoid using common subnets like 192.168.2.0 for your tunnel network. Use something obscure like 172.23.24.0/24
-
I have made research that the "redirect gateway" function doesn't work as expected.
So I recommend to uncheck this function and enter your local network beneath at "IPv4 Local Network/s". Routes to network entered here are pushed to clients. -
viragomann, I really appreciate the suggestion. I thought for sure this would be it because that's something that wasn't done in the video. Unfortunately, I unchecked it and am getting the same behavior, except my traffic still comes out of my IP.
Also, I don't know pretty much anything about routes, but I did a route print and in there was the following line:
192.168.1.0 255.255.255.0 192.168.2.5 192.168.2.6 30
While I don't understand the last 3 columns, it seems to me that the first two would indicate the route exists, right? The IP I'm trying to ping is currently 192.168.1.103, so I don't see why it wouldn't work. Am I barking up the wrong tree?
Update: Also, doing a tracert, hop 1 goes to 192.168.2.1, and then it stops there. It doesn't go any further.
-
The route looks correctly. What the columns show, can be seen in headline of the IPv4 Routing table: destination, mask, gateway, interface, metric
Metric is the priority for this route. That means if there are more than one route entries for the same destination the system take the one with the lower metric value.
So to you have a further route for the network 192.168.1.0 255.255.255.0 or another one which includes this network?I have no idea where the host IP 192.168.2.1 in tracert comes from. If everything is configured correctly your system shouldn't know this IP.
It's not easy to give help with such less informations. We should know all networks configured on any interface of your system and the whole output of route print.
As biggsy mentioned it is recommended to assign a rarely used subnet to the VPN tunnel and to your home network to avoid conflicts.
-
Post your server1.conf.
What network is the client on?
Also, we can troubleshoot the tunnel, but all the work may be moot because looking at your endgame… you may have setup the wrong solution. If you want your clients on the same network as your lan you need to go bridged instead of routed. Using a routed and forcing the clients down the tunnel (Redirect Gateway) just forces all traffic down the tunnel it won't put your clients on the same subnet as your lan.
If what you're trying to accomplish (Steam In-Home Streaming) relies on broadcasts or the VPN client to be on the same subnet as your lan, a routed solution is not going to work.
-
Marvosa, you're right I very well may be using the wrong solution. If there is a better way to go about it I am completely open to it, and in fact if there's a way to have anything that connects to my VPN just be directly on the same subnet that's what I want but haven't found a way to do so yet. Thanks again, and here is the server1.conf. (I removed my public IP, but everything else is untouched.)
Edit: After looking into what you said, I'm pretty sure I do just want it bridged. I don't want them to be segregated in any way. I'm tinkering with it trying to set the "Device Mode" to "tap" without much luck yet.
dev ovpns1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local <my public="" ip="" is="" here="">tls-server
server 192.168.2.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
username-as-common-name
auth-user-pass-verify /var/etc/openvpn/server1.php via-env
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 443
management /var/etc/openvpn/server1.sock unix
max-clients 10
push "route 192.168.1.0 255.255.255.0"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo</my>