Accessing LAN resources with remote OpenVPN iOS clients
-
I setup a bare-bones 2.3.3-RELEASE-p1 (amd64) machine using Intel Atom (4GB RAM 60GB SSD dual 10/100 Intel server card). I setup OpenVPN server (Remote Access SSL/TLS) with corresponding CA and Server Certificate. For my experiment:
LAN subnet: 192.168.1.0 / 255.255.255.0
pfSense box: 192.168.1.1
IPv4 Tunnel Network: 192.168.10.0/24 (defined in the OpenVPN setup tab)
OpenVPN settings: UDP / 443 tun Crypto: AES-256-CBC/SHA1 D-H Params: 2048 bitsThe firewall rules are the bare-bones rules default when setting up the pfSense box and enabling OpenVPN server. I setup a WAN rule to allow incoming connections on the OpenVPN port number. The OpenVPN rule is the default IPv4 * * * * * * rule.
I used the Client Export for iOS and imported to both iPad and iPhone test platforms with updated OpenVPN app. Both devices were tested by going to the "Whats My IP" website to confirm they were natively operating on their respective 4G addresses. After successfully logging into the pfSense OpenVPN server over 4G, both devices displayed the local pfSense WAN IP address, showing they were successfully routing traffic through the OpenVPN tunnel. Internet-based traffic (app store, web browsing, etc) were confirmed to be operating through the OpenVPN tunnel by observing traffic monitoring at the pfSense box.
However, when a web browser was directed at a local LAN resource (e.g. the pfSense web administration interface at 192.168.1.1), the remote clients were not able to access LAN.
I read a lot of forum posts and attempted a push "route 192.168.1.0 255.255.255.0"; in the Custom Options box, but this did not work. There are multiple forum posts related to accessing LAN resources with remote VPN clients, but I was not able to locate a solid solution.
What is the solution to allow remote OpenVPN clients to access LAN resources behind a pfSense OpenVPN server?
-
on your openvpn interface, do you have a rule allowing access to the internal LAN?
-
Attached are the rules. I used the most basic IPv4 * * * * * * rule under the OpenVPN tab. The LAN tab has the auto-generated pass rules. I tried a few pass rules under the LAN tab and ultimately tried a "pass all" * * * * * * rule.
![MWSnap 2017-04-29 09_50_30.jpg](/public/imported_attachments/1/MWSnap 2017-04-29 09_50_30.jpg)
![MWSnap 2017-04-29 09_50_30.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-29 09_50_30.jpg_thumb)
![MWSnap 2017-04-29 09_50_48.jpg](/public/imported_attachments/1/MWSnap 2017-04-29 09_50_48.jpg)
![MWSnap 2017-04-29 09_50_48.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-29 09_50_48.jpg_thumb)
![MWSnap 2017-04-29 09_57_31.jpg](/public/imported_attachments/1/MWSnap 2017-04-29 09_57_31.jpg)
![MWSnap 2017-04-29 09_57_31.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-29 09_57_31.jpg_thumb)
![MWSnap 2017-04-29 10_02_25.jpg](/public/imported_attachments/1/MWSnap 2017-04-29 10_02_25.jpg)
![MWSnap 2017-04-29 10_02_25.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-29 10_02_25.jpg_thumb) -
the rules you were adding on the LAN tab wouldnt be used because there is a 'allow any' thats above it by default.
try changing a part of your config from sending specific networks to be tunneled, to be a full gateway redirect.
https://snag.gy/NfoGb6.jpgalso post your openvpn config please.
-
I installed a fresh SSD and installed 2.3.3-RELEASE (amd64) and repeated the identical configuration from scratch.
The OpenVPN under 2.3.3-RELEASE (amd64) allowed access to LAN resources. The OpenVPN under 2.3.3-RELEASE-p1 (amd64) does NOT allow access to LAN resources.
Next, I will upgrade from 2.3.3 to 2.3.3_1 and see if this breaks the LAN access.
UPDATE 1: Upgrading a working configuration from 2.3.3 to 2.3.3_1 does not break the OpenVPN LAN access.
UPDATE 2: Changing an OpenVPN setting (i.e. SHA1 to SHA256) after upgrading breaks OpenVPN LAN access. -
I noticed in the OpenVPN Wizard the setting for Local Network. Screenshot of wizard attached.
I set the OpenVPN Tunnel Network to 192.168.2.0/24 and the LAN is 192.168.1.0/24.
However, in the OpenVPN settings, there is no setting for Local Network. Where does the Wizard store the Local Network, whereas it never appears on the OpenVPN settings screens (also attached)?
Summary:
OpenVPN wizard has entry for both Tunnel Network and Local Network
OpenVPN settings has entry only for Tunnel Network
Where does the Wizard store the Local Network entry? How can I find, view, or edit this setting later?![MWSnap 2017-04-30 19_10_38.jpg](/public/imported_attachments/1/MWSnap 2017-04-30 19_10_38.jpg)
![MWSnap 2017-04-30 19_10_38.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-30 19_10_38.jpg_thumb)
![MWSnap 2017-04-30 21_01_14.jpg](/public/imported_attachments/1/MWSnap 2017-04-30 21_01_14.jpg)
![MWSnap 2017-04-30 21_01_14.jpg_thumb](/public/imported_attachments/1/MWSnap 2017-04-30 21_01_14.jpg_thumb) -
when redirect gateway is checked it doesnt show the option for local networks. This is because the VPN tunnel will be a full tunnel, and send ALL traffic across the tunnel.
-
The network you are connecting from isn't also using 192.168.1.0/24 as its LAN is it?
What you are trying to do "just works" for thousands if not hundreds of thousands if not millions of people. All day, every day, no days off. There is no trick to making it work except for figuring out what you did wrong.
Step 1: Stop looking at 2.3.3_1 vs 2.3.3 as source of the problem. It is not there.
Step 2: Stop looking at pfSense as the problem.
When those two truths are accepted you will be on your way to finding whatever it is that you have configured incorrectly.
UPDATE 1: Upgrading a working configuration from 2.3.3 to 2.3.3_1 does not break the OpenVPN LAN access.
UPDATE 2: Changing an OpenVPN setting (i.e. SHA1 to SHA256) after upgrading breaks OpenVPN LAN access.You can't just change server settings without making the corresponding changes to the client configurations. And UPDATE 2 is more of a connect or can't connect scenario. Not a can or cannot access some resources scenario. Slow down, work a hop at a time, check DNS resolution and pings. Take packet captures if you have to and figure out where you sent your traffic the wrong way.