In my case, the users weren't able to connect to the server through SSH because their traffic was going through the Secondary WAN address. I have 2 WAN ips configured on my pfsense firewall.
I used tracert google.com on the client system to check the path. This is how if foundout that the traffic is going through the secondary WAN address. So I added both WAN ips in the SSH access list and the issue got resolved. Now we are able to connect via ssh without any problem.

Hi,

Some testing is needed.

Like :
The WAN interface used by the OpenVPN server is still valid ?
Is it listing on that NIC ? The port is ok ?
There is a WAN firewall rule ?
Put a switch on the WAN side, hook a PC into it, and hit the WAN pfSense IP direct : does it work ?
Is the upstream router set up correctly ? New device means often : new WAN IP, so upstream NATting will/can change.

Does the OpenVPN server starts ?
What do the OpenVPN server logs say ?

When you see auth problems, certs etc should be checked.
Logs will tell a lot, of course.

IMO it's impossible to tell active directory domain member to not look for dns record of domain name.

Here is some more information which might help.
My Router is behind my ISP's Router, so I suppose is 'double NATed'?? If that helps.
I have opened The Firewall on the LAN to everything to do with the AirVPN Server address.
This is the config the server is using:

dev ovpnc1 verb 4 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-256-CBC auth SHA512 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.1.153 engine cryptodev tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote xxx.xxx.xxx.xxx 443 udp4 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-crypt /var/etc/openvpn/client1.tls-crypt ncp-ciphers AES-256-GCM:AES-256-CBC comp-lzo no resolv-retry infinite route-noexec fast-io explicit-exit-notify 5 sndbuf 262144 rcvbuf 262144 client persist-key persist-tun remote-cert-tls server prng sha256 64 mlock auth-nocache

and here is the info from the ovpn file with the keys in:

dev tun remote xxx.xxx.xxx.xxx 443 resolv-retry infinite nobind persist-key persist-tun auth-nocache verb 3 explicit-exit-notify 5 rcvbuf 262144 sndbuf 262144 push-peer-info setenv UV_IPV6 yes remote-cert-tls server cipher AES-256-CBC comp-lzo no proto udp key-direction 1

and the Log Output. The only thing I can spot is this Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key when the Encryption Algorithm is AES-256-CBC (256bit key, 128 bit block)
Also the instructions tell you to use Allowed NCP Encryption Algorithms: AES-256-GCM but the above is using AES-256-CBC, I have tried with both, but no good.

Oct 4 15:34:09 openvpn 41002 MANAGEMENT: Client disconnected Oct 4 15:34:09 openvpn 41002 MANAGEMENT: CMD 'state 1' Oct 4 15:34:09 openvpn 41002 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock Oct 4 15:34:04 openvpn 41002 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:443 Oct 4 15:34:04 openvpn 41002 UDPv4 link local (bound): [AF_INET]192.168.1.153:0 Oct 4 15:34:04 openvpn 41002 Socket Buffers: R=[42080->262144] S=[57344->262144] Oct 4 15:34:04 openvpn 41002 TCP/UDP: Preserving recently used remote address: [AF_INET]185.103.96.130:443 Oct 4 15:34:04 openvpn 41002 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server' Oct 4 15:34:04 openvpn 41002 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client' Oct 4 15:34:04 openvpn 41002 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Oct 4 15:34:04 openvpn 41002 Control Channel MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ] Oct 4 15:34:04 openvpn 41002 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 4 15:34:04 openvpn 41002 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Oct 4 15:34:04 openvpn 41002 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 4 15:34:04 openvpn 41002 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Oct 4 15:34:04 openvpn 41002 Initializing OpenSSL support for engine 'cryptodev' Oct 4 15:34:04 openvpn 41002 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 4 15:34:04 openvpn 41002 mlockall call succeeded Oct 4 15:34:04 openvpn 41002 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock Oct 4 15:34:04 openvpn 40744 library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10 Oct 4 15:34:04 openvpn 40744 OpenVPN 2.4.9 armv6-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020

Hopefully this additional infomation might jog a memory somewhere.

That is asymmetrical mess

assmess.png

If you want to use pfsense as downstream routers from your USGs then connect them with transit networks..

2 transits.png

You could also just solve this with just a transit between your 2 USGs.. 1 pfsense between the 2 of them with leg connected to each USG which would be the transit network connected to each USG.

You could also use port forwarding and source natting to solve the problem on every host in your different 20.11 and 20.12 networks. Or host routing so your flow would look like this.

nat-port.png

Problem solved by unchecking "username as Common Name"

27e7e01e-792b-4ce8-9a5b-f2f2ba671770-image.png

fe695c48-00af-41b9-a6be-a71b7e21d13c-image.png

3dd995af-fb95-4ad1-a2a5-fae44f170ef7-image.png

c6fbe7f8-5a34-4199-a2b6-6175f1706ce6-image.png

b19ce9cf-098a-4e1e-97e2-ec91d1d927b8-image.png

8c13ee03-186b-47c2-89a4-a77a30a5579a-image.png

You may set there any parameters you want. Mainly you have to enter the client certs common name, a specific tunnel network (/30), the "IPvX Local Network/s" as you already have in the server settings and the "IPvX Remote Network/s", where you have to enter the clients site local networks.

johnpoz...thank you for your replies. Very helpful.

Gertjan...it seems after I configured OpenVPN for the second time on pfSense, the 6 minute time is no longer an issue, at least at the time of this post. If anything changes, I'll repost.

@PhlMike said in PFSense as OpenVPN Client:

Can I load an .ovpn file or split it up to get it loaded on a pfSense firewall to connect as a client to another service?

Hi,

Of course, many of us use this to - say, connect to a VPN provider... (with provider .ovpn file)

You can't load * .ovpn directly, but you need to configure the client from this file

For example, read this description:

https://www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn/

The .ovpn file is quite provider specific, so be sure to consult it beforehand...

like:
a9b85c4c-711c-4385-9c64-336d2ee85702-image.png

I don't know the ins and out of how this security device works. But clearly it has a gateway (pfsense). And there is no reason to do the source natting of your vpn connection.

From what you have shown the device is answering.. But was showing RST from your client, and Fin,ack from your device to your clients.. Both are ways to END a conversation.

So what is actually the issue with vpn vs internet not sure? But from what you have shown pfsense is doing what its told to correctly.

I would suggest you sniff on pfsense opt1 interface for your device IP. Set the sniffing packets limit from 100 to 0 so you can see the full conversation... Then start a conversation from internet doing your normal forwarding..

So you can see what is all involved with normal working conversation. Then make sure you kill any states for this conversation.. Reboot the device say, and then doing the same sniffing and talking from your vpn client.. So you can see what might be different?

Off the top of head, thing that might be different while your on the actual internet with your client doing port forwarding on pfsense is you have access to internet from your client via the same connection. While your vpn connection would change that sort of connection, etc.

Its possible your device phones home and checks something before allowing connection? It could be all kinds of things. But from what you have shown pfsense is doing exactly what it should be doing, and again doesn't care if your coming from the internet or a vpn.. It just allows the traffic or it doesn't..

Nevermind, the reason was that the openvpn had topology net30... changed it to subnet and things are working!

@viragomann said in Cannot access LAN resources:

Have you updated the "Local networks" in the server settings to your new LAN subnet?

Forgot that, fixed now.

On WAN interface you have two equal OpenVPN wizard rules. So you may delete one.

I did delete the whole vpn server and reconfigured it with wizard before posting here so apparently it made duplicate rules. Fixed now.

You're allowing access to anywhere on the OpenVPN tab, so ensure you can trust all clients.

I'm the only one using the VPN and I'll add SSL/TLS auth for more security.

Thank you again!

If the --client-to-client option (Inter-client communication) is active, these packets are not exposed to the server host (pfSense in this case).
Firewall rules will therefore not have any effect.
https://community.openvpn.net/openvpn/wiki/HowPacketsFlow

Check the client(s) firewall.

https://redmine.pfsense.org/issues/10650

-Rico

Dear viragomann,

Thank you a lot for your answer.

I just resolved my problem, problem I created myself.

Fyi, let me answer to you :

Yes I see the route on both sides and firewalls rules are ok.

Also, I'm not doing the site to site only but the multi-purpose instance (sorry) :

The solution was : (I'm ashamed), I did not realize that physicaly unpluging the interface deactivate the said interface and then make it unreachable, even under an icmp ping... I'm sorry for the inconvenience.

Thanks again,

Yorik