Thank you very much! That works perfect!

@dotdash
Thank you for this helpful hint.

I did this:

VPN - openvpn - Client Specific overriedes - add

common name: xxx IPv4 Tunnel network: 192.168.10.200/24 (network 192.168.10.x is the ipv4-tunnel I also use for my other "normal" users without fixed ip address) IPv6-Tunnel network: fd73:123:456:2::200/64 (network fd73:123:456:2 is the ipv6-tunnel I also use for my other "normal" users without fixed ip address)

Now I can create firewall rules (Firewall/Aliases/Edit) specific for my clients.

Ok this is "solved", if you can call it that. I gave up trying to get OpenVPN running on the Robustel. I instead used a OpenWRT based router to connect to the very same pfSense, had it working in under 10 minutes.

Here is a utube from Lawrence about Suracata and encryption. I am not a IT pro. Maybe some can let me know if you find this accurate?

https://www.youtube.com/watch?v=7gZYbIr_Qj4

Figured it out on my own, had to reach the pfSense Book, some googling, and testing on a standalone station. Forum was not much help, honestly.

What I did:

Put a deny all IPv4+6 right above the default OpenVPN allow any any rule

Only permitted the ports needed to allow file sharing and AD authentication (Google them. It should be 135, 137-139, 88, 445, etc. if you have older equipment)

I then made an alias for my client IP, Internal IPs I need to manage, and ports for that management. So ports 3389,22,80,443, etc. It's whatever you need for your situation.

When making new users for other clients I forced them to a single IP within the Client Specific Override and made sure to allow random ports for concurrent connections

Make new users and assign them into groups if they need special access, like IT needs to RDP to a server etc.

DO NOT USE THE SAME USER ACCOUNT FOR ALL CLIENTS, you can do this but it's a liability, hard to manage, and have organized logging. If it's just a few people, I can understand it, but for 50-100? make the users or link to an authentication server

That got me up and going for the most part, I had to work with legacy VMWare, so I had to reinvent the wheel with some of the virtual networking/bridging.

TIP:

Read the pfSense Book first for any questions you have Understand the rule processing order Group interface rules are in a higher order than your interface rules, so filter the group first, the interface LAN should be filtered afterwards to follow suit.

This is just what I did to fix my problem, I've found decent guides with these links and this documentation... (see below)

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

https://chrislazari.com/pfsense-setting-up-openvpn-on-pfsense-2-4/

https://www.informaticar.net/openvpn-on-pfsense-enable-access-to-the-lan-resources/

keep in mind that the last two links do not highlight security after making it work, that's what the pfSense book is there to provide. Read page 172 and finish that chapter to understand it. Then, like I said, test it yourself and verify your rules work. I wasn't able to find a direct answer for my question and struggles, so I'm hoping this helps someone too. I've attached pictures too because maybe I'm wrong and there's a better way to do it.

FilteredOpenVPNGroup.png

If this is wrong, feel free to correct me and give me a better solution.

Thanks

Well, this morning everything is back to normal...
I have no clue about what happened, but anyway sorry for the noise.

@viragomann wow, that was it. when I checked the "Don't pull routes" option, that was exactly what I needed to get it to work. Now, VLAN 10 goes through the WAN and VLAN 50 goes through the VPN. Thanks very much!

@velupazhani
You have to add an additional (or multiple if needed) phase 2 to the IPSec configuration for the OpenVPN tunnel.
In the OpenVPN server settings add the network(s) behind the IPSec to the "Local networks" to push the route to the clients.

The solution to my problem was to ditch policy-based IPSec and switch to route-based IPSec. This reduces the number of phase 2 entries by a lot but requires more static routes. IMHO it's better this way because there's no intransparent mix of different ways of routing packages between their destinations. Now everything is just in the routing table.

@ReneMG said in pfSense OpenVPN server, Asus RT-AC66U client:

Try this:

appropriate 👍

There is no limitation in pfSense, you can have as many Users or OpenVPN Instances as you want.
The hardware depends on your WAN and VPN throughput, not really the number of VPN users.

-Rico

Good morning,
As of 1.8. I can confirm that the secondary WAN is up and working ”as before” - the FUP was reset.

So it really is a ISP “feature” - they block access between their clients. So thanks to my multi WAN setup i was not aware of this limitation and “suddenly” i experienced that once the secondary WAN was not working thanks to the applied FUP.

Thanks to all of you for your support.

@charry2014

As I mentioned, I don't have experience with he.net, so perhaps someone else here can help you with it.

Apart from specific iroutes on each client.

If you enable peer 2 peer then routing is done inside vpn server and you cannot control it with pf firewall rules

You could route just the phone ip's but its a bit crude.
I would route /18 and enforce any filtering on the tomato level.

@kamate said in how to import ovpn file:

But i cannot find exact informations about how to import the ovpn file into pfsense.

Hi,

it is not literally an import, but that's the way to do it... 😉

these links (VPN services) describe the method and more...

-simply apply to your own VPN client settings

https://www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn/
https://support.nordvpn.com/Connectivity/Router/1089079142/pfSense-2-4-4-setup-with-NordVPN.htm

do not use special things that depend on the VPN provider

BTW:
if possible use cipher aes-256-gcm instead of aes-cbc

Thanks for the NSIS proposal. I will check it out.

@johnpoz Ha! No, it's AES-256-CBC 😁