Did you manage to connect to Purepvn?

@DominikHoffmann
From the documentation....

8043c07a-b660-4ac6-85d0-8a6e11dda674-image.png

@viragomann wow it worked, thank you! I had these entries, but they contained old configs!

@PierreFrench
Shared key is deprecated, as mentioned, and I didn't use it for years.
So I don't know if and how client specific overrides and the client side LAN routing work with it.
I think, it should if xou state the correct client name and the respective remote networks.

@johnpoz hi ! thanks ! it is due to bad gateaway config in my exi server (i set 2.100 instead of 2.1, i don't know why...)

Thank a lot !

@AwesomeRob Thank you for that :)

I just tested with pfSense+ 24.03 and it still uses 2.6.8_1

However if you then select the "development snapshot" branch under system update

and ssh into pfSense and run

pkg install openvpn

then it does update to 2.6.11

Not the cleanest option, but is a way to get it upgraded.

After doing that upgrade then can always change the system update back to stable.

Not sure if this may complicate when pfsense 24.08 is released (roadmap goal is August 2024) - however this may be our best option for now.

For anyone wondering, here is output from my pfsense+ 24.03 after manually doing above described steps (including changing system upgrade option back to stable version) and then running openvpn --version

OpenVPN 2.6.11 amd64-portbld-freebsd15.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO] library versions: OpenSSL 3.0.13 24 Oct 2023, LZO 2.10 DCO version: FreeBSD 15.0-CURRENT #0 plus-RELENG_24_03-n256311-e71f834dd81: Fri Apr 19 00:28:14 UTC 2024 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-24_03-main/obj/amd64/Y4MAEJ2R/var/jenkins/workspace/pfSense-Plus-snapshots-24_03-main/sources/FreeBS Originally developed by James Yonan Copyright (C) 2002-2024 OpenVPN Inc <sales@openvpn.net> Compile time defines: enable_async_push=yes enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_dco=yes enable_dco_arg=yes enable_debug=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_pam_dlopen=no enable_pedantic=no enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=yes enable_strict_options=no enable_systemd=no enable_unit_tests=no enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_openssl_engine=auto with_sysroot=no

@viragomann Sorry there was some confusion on my end. The abbreviation CSO was not clear to me, but after some further searching it became clear and I added the route to the remote networks tab for the subnets on the client side. Thanks for your help, it works now!

@micneu tut mir leid, ich bin ja auch selten dumm, wenn man schon deutsch spricht sorry
@johnpoz thx to move :)

So, I found a problem in the server configuration. I had to include the remote networks in the IPv4 Local network(s) section. Now it says:

192.168.1.0/24,192.168.34.0/24,192.168.42.0/24,192.168.45.0/24,192.168.48.0/24,192.168.51.0/24,192.168.54.0/24

and it works for some of those, but only for some.

I compared the two client configurations on 192.168.34.1 and 192.168.54.1:

<openvpn> <openvpn-client> <auth_user></auth_user> <auth_pass></auth_pass> <proxy_user></proxy_user> <proxy_passwd></proxy_passwd> <vpnid>1</vpnid> <dco>disabled</dco> <protocol>UDP4</protocol> <dev_mode>tun</dev_mode> <interface>wan</interface> <ipaddr></ipaddr> <local_port></local_port> <server_addr>hoffmann.homeunix.net</server_addr> <server_port>1194</server_port> <proxy_addr></proxy_addr> <proxy_port></proxy_port> <proxy_authtype>none</proxy_authtype> <description><![CDATA[Ipheion Solutions management interface]]></description> <mode>p2p_tls</mode> <topology>subnet</topology> <custom_options>verify-x509-name &quot;server&quot; name</custom_options> <caref>66d22c7d1f7c9</caref> <certref>66d22c7d9e38e</certref> <crlref></crlref> <tls>********</tls> <tls_type>auth</tls_type> <tlsauth_keydir>1</tlsauth_keydir> <digest>SHA256</digest> <tunnel_network></tunnel_network> <tunnel_networkv6></tunnel_networkv6> <remote_network>192.168.54.0/24</remote_network> <remote_networkv6></remote_networkv6> <use_shaper></use_shaper> <allow_compression>asym</allow_compression> <compression></compression> <auth-retry-none></auth-retry-none> <passtos></passtos> <udp_fast_io></udp_fast_io> <exit_notify>none</exit_notify> <sndrcvbuf></sndrcvbuf> <route_no_pull></route_no_pull> <route_no_exec></route_no_exec> <dns_add></dns_add> <verbosity_level>1</verbosity_level> <create_gw>both</create_gw> <data_ciphers>AES-128-GCM,AES-256-CBC</data_ciphers> <data_ciphers_fallback>AES-256-CBC</data_ciphers_fallback> <ping_method>keepalive</ping_method> <keepalive_interval>10</keepalive_interval> <keepalive_timeout>60</keepalive_timeout> <ping_seconds>10</ping_seconds> <ping_action>ping_restart</ping_action> <ping_action_seconds>60</ping_action_seconds> <inactive_seconds>0</inactive_seconds> </openvpn-client> </openvpn>

and

<openvpn> <openvpn-client> <auth_user></auth_user> <auth_pass></auth_pass> <proxy_user></proxy_user> <proxy_passwd></proxy_passwd> <vpnid>1</vpnid> <dco>disabled</dco> <protocol>UDP4</protocol> <dev_mode>tun</dev_mode> <interface>wan</interface> <ipaddr></ipaddr> <local_port></local_port> <server_addr>hoffmann.homeunix.net</server_addr> <server_port>1194</server_port> <proxy_addr></proxy_addr> <proxy_port></proxy_port> <proxy_authtype>none</proxy_authtype> <description><![CDATA[pfSense-UDP4-1194-millers-config_OpenVPN]]></description> <mode>p2p_tls</mode> <topology>subnet</topology> <custom_options>verify-x509-name &quot;server&quot; name</custom_options> <caref>66bd527e46839</caref> <certref>66bd527ec81c0</certref> <crlref></crlref> <tls>********</tls> <tls_type>auth</tls_type> <tlsauth_keydir>1</tlsauth_keydir> <digest>SHA256</digest> <tunnel_network></tunnel_network> <tunnel_networkv6></tunnel_networkv6> <remote_network></remote_network> <remote_networkv6></remote_networkv6> <use_shaper></use_shaper> <allow_compression>asym</allow_compression> <compression></compression> <auth-retry-none></auth-retry-none> <passtos></passtos> <udp_fast_io></udp_fast_io> <exit_notify>none</exit_notify> <sndrcvbuf></sndrcvbuf> <route_no_pull></route_no_pull> <route_no_exec></route_no_exec> <dns_add></dns_add> <verbosity_level>1</verbosity_level> <create_gw>both</create_gw> <data_ciphers>AES-128-GCM,AES-256-CBC</data_ciphers> <data_ciphers_fallback>AES-256-CBC</data_ciphers_fallback> <ping_method>keepalive</ping_method> <keepalive_interval>10</keepalive_interval> <keepalive_timeout>60</keepalive_timeout> <ping_seconds>10</ping_seconds> <ping_action>ping_restart</ping_action> <ping_action_seconds>60</ping_action_seconds> <inactive_seconds>0</inactive_seconds> </openvpn-client> </openvpn>

The only real differences are in

the description, the CA reference, the cert reference, and that the second has remote network specified, client side.

@viragomann
Thank you very much for your great Idea!

I will check this out.
At the moment the Client is not setting the IP from Client Specified Override and we don't know why.
After this weekend it will work, I am sure.

Greetings

@viragomann ok thanks I'll do some tests

@Debian-Linux
So your setup should look like this in the future:

WAN ---- Forti ---- LAN | |--- pfSense-VPN-GW

?
In fact pfSense is a LAN device in this case. Maybe there is a switch in between, but this doesn't matter.

Yes, you can do this.

You have to separate pfSense from the LAN, however. Create an additional subnet (maybe VLAN) between the Fortigate and pfSense. Assuming you connect the WAN interface of pfSense to the Forti, state the Forti IP (of the VLAN) as upstream gateway in the interface settings. On the Fortigate forward the OpenVPN traffic to pfSense. On the Forti create static routes for the OpenVPN tunnel networks (assuming you run an access server. For a site-2-site create static routes for the remote networks) and point them to pfSense. On pfSense go to NAT > Outbound, enable the hybrid mode and add a rule for the destination of your local networks (can be an alias) to the WAN interface and set it to "no NAT". This enables the destination device to see the real client source IP instead of the pfSense WAN IP.

@McMurphy
The VPN_GW might arise from assigning an interface to an OpenVPN instance.
So go to Interfaces > Assignments and check if there is a related existing interface. If so delete it.

@DominikHoffmann
If the clients firewall rules on the VPN interface allow access I'd expect the ping to succeed.

@bebewold said in accessing work VM through a VPN:

but I don't see why it would not work

For starters its a rebind.. Did you set whatever your work domain up as private?

https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html#dns-rebinding-protections

Security has little to do with it to be honest.. It has never been best practice to put rfc1918 in public dns..

Do they not even run a local dns at your work?

@Snailkhan

Hi,
I am implementing it right now and also had this question.

Just made it work though. Here is my example with Windows Server 2022 Standard:

Open Network Policy Server. Create new network policy in NPS. Give it a name for example hagrid-static-ip. Add a condition. I did not find a possibility to add a specific user, only a group. So, added a group with one user Hagrid just for a test. At Settings tab go to RADIUS Attributes => Standard. Add an attribute "Framed-IP-Netmask". My OpenVPN network is 10.10.10.0/24, so i put there 255.255.255.0 mask. At the same Settings table to to IP Settings. Choose "Assign a static IPv4 address" there. Put an address, for example 10.10.10.55. Save the policy and connect to OpenVPN Server on pfsense with Hagrid user. IP 10.10.10.55 must be assigned.

I do not claim that it is a valid and good to follow solution. Just sharing my ongoing experience.
My end goal is assigning pools to different groups of users and then manage access for them in pfsense firewall. For example group admins - pool 10.10.10.10-20. This pool is added to alias in pfsense firewall and rules afterwards for this alias.

This is quite typical task, I think. So, maybe there are another posts with much better explanations.

I also used this article https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/client-parameters-radius.html, which gave me an idea to add mask as an additional attribute and made it work eventually.

@damianhl said in Block connection attemp from internal LANs:

there are many servers, printers, etc, with fixed IPs

You don't have to move them all at once.. But this is normally why you would use dhcp, so you could easy migrate 100 if not 1000s of devices to a new IP scheme.

But you can for sure just move one at a time if you so desired.. The outage on any specific device would be very short - the time it takes to come up on its new IP.

Such a scenario is one of the scenarios where it makes sense to run multiple layer 3 on the same network for a time, ie transition.

If me, I would as your migrating devices to a better network IP range change them to dhcp with a reservation so say server 1 always gets IP X, server 2 always gets IP Y, etc..

I would change your network to your new IP range, then put a vip on pfsense for its old 150 address, etc. Then slowly move over the devices to dhcp on the new network assigning the IP address you want for each device. You would just need to change the port forwards you currently have as you do.