@gwaitsi
That makes no sense for a client, I think. The only useful information you could get out would be, if the server cert is revoked.

And it would require that ExpressVPN provides a CRL in the internet and that OpenVPN can request it. In the client settings you can only state a local CRL, which make no sense here at all.
You can look in the CA certificate to check out if there an URL for the CRL stated. But I don't know if OpenVPN requests it.

@divya-0 said in Regarding CPU & Swamp Space full:

For remote console, new to access freebsd console like putty with using ssh

In that case, as you'll be using port 22 TCP, so open this port.
Or again : use a VPN. Nothing to open, no security issues.

If you are using a 'stock' pfSense with 2 Gbytes, and it starts to use swap, consider your system unstable.
SSH access, and also GUI access can tell you what process use what memory and when.

You might even hit a bug that was solved many years ago.
The answer was : upgrade 😊 This answer still applies.
As said : who recalls issues of the last version ? Nearly no one.
2.4.4 ? Why should we ?

Update, for DSM7:

The steps to configure the OpenVPN server in pfSense (v2.6.0) remain the same as described above in the OP.

When exporting: go to Client Export and choose "Do not include OpenVPN 2.5 settings in the client configuration."
Select Inline Configuration -> Most Clients. It will export you an .ovpn file with the keys/certs built-in.
Before uploading to Synology NAS, open this file in a text editor and comment out "ncp-disable" directive, and change "udp4" to "udp" (if present).

On Synology DSM7 side, subtle changes:

In Synology NAS, go to Control Panel > Network > General > Advanced Settings button. Check "Enable Multiple Gateways".
After that go to, Network Interface > Create > Create VPN profile, choose OpenVPN. Input your username and password you've created just for this and browse for your .ovpn file. Make sure you select to restart connection if breaks. It should accept it immediately. Select the new VPN Connection and click Connect button.

As far as I noticed, there's no need to trick around anymore with starting the connection at boot, DSM 7 will automatically restart the VPN connection after it reboots, as long as you have ticked the option to reconnect when connection is lost.

@hoserman
This is a straight forward set up. You only need a rule on the OpenVPN interface, which allows only upstream traffic and to be secure an additional that blocks access to local subnets.

Do you run multiple OpenVPN instances or only one? If the latter you can run the wizard and state to direct the whole upstream traffic over the VPN and provide a public DNS server.
Then you should just have to add a block rule to the top of the OpenVPN rule set for your local networks.
Best practice is to block all private network ranges by adding an RFC 1918 alias and use it in the block rule as destination.

If you provide pfSense for DNS resolution you have to allow the access by an additional rule.

@wmw509 Post the rules on your OpenVPN tab. Also, did you assign your tunnels to interfaces? If so, are there rules allowing traffic on those interfaces?

@durgadas
I described a scenario of excluding one or multiple (with the help of an alias) IP from the default route. That's the TO's requirement I understood.
Why do you think we're talking about the opposite here?

edit - i solved my own frusturation by deselecting DCO after realizing airvpn is ovpn 2.5.
everything is working wonderfully.

sorry to add clutter to the forums

I found the solution. I set the following on the OpenVPN configuration and now everything is working.

link-mtu 1400;

I don't fully understand why that was needed since my network is using the default 1500 MTU, but it solved the problem.

Shoutout to the support I got on Reddit to resolve the issue.

ssh to pfsense.
choose 8) Shell

[22.05-RELEASE][root@yyy]/root: openssl list -digest-algorithms RSA-MD4 => MD4 RSA-MD5 => MD5 RSA-MDC2 => MDC2 RSA-RIPEMD160 => RIPEMD160 RSA-SHA1 => SHA1 RSA-SHA1-2 => RSA-SHA1 RSA-SHA224 => SHA224 RSA-SHA256 => SHA256 RSA-SHA3-224 => SHA3-224 RSA-SHA3-256 => SHA3-256 RSA-SHA3-384 => SHA3-384 RSA-SHA3-512 => SHA3-512 RSA-SHA384 => SHA384 RSA-SHA512 => SHA512 RSA-SHA512/224 => SHA512-224 RSA-SHA512/256 => SHA512-256 RSA-SM3 => SM3 BLAKE2b512 BLAKE2s256 id-rsassa-pkcs1-v1_5-with-sha3-224 => SHA3-224 id-rsassa-pkcs1-v1_5-with-sha3-256 => SHA3-256 id-rsassa-pkcs1-v1_5-with-sha3-384 => SHA3-384 id-rsassa-pkcs1-v1_5-with-sha3-512 => SHA3-512 MD4 md4WithRSAEncryption => MD4 MD5 MD5-SHA1 md5WithRSAEncryption => MD5 MDC2 mdc2WithRSA => MDC2 ripemd => RIPEMD160 RIPEMD160 ripemd160WithRSA => RIPEMD160 rmd160 => RIPEMD160 SHA1 sha1WithRSAEncryption => SHA1 SHA224 sha224WithRSAEncryption => SHA224 SHA256 sha256WithRSAEncryption => SHA256 SHA3-224 SHA3-256 SHA3-384 SHA3-512 SHA384 sha384WithRSAEncryption => SHA384 SHA512 SHA512-224 sha512-224WithRSAEncryption => SHA512-224 SHA512-256 sha512-256WithRSAEncryption => SHA512-256 sha512WithRSAEncryption => SHA512 SHAKE128 SHAKE256 SM3 sm3WithRSAEncryption => SM3 ssl3-md5 => MD5 ssl3-sha1 => SHA1 whirlpool

now to openssl project...

@jarhead , thanks, I just double checked again: On site B I have the site A openvpn client net allowed in the peer.

In the mean time I did set up an OpenVPN server on site B, put the openvpn client net of it in the WireGuard allowed list of the peer in site A. From Site B's OpenVPN clients, I can connect through the tunnel... site A is not working.

@gertjan Thank you guys for your support

@johnpoz I found my very stupid mistake! I did not ebabled the rule that i created! :) So now everything works like charm! Thank you very much, John! Image3.jpg

@gertjan I asked my ISP to get a real public IP and got one ... but sadly for a monthly fee.
This solved the problems I had with OpenVPN.
Thanks again for all your support ... I have learned alot about CG-NAT ... that was a white spot on my map.

@help-group

Have a look at pfsense openvpn server with freeradius.

@rm85

Found it, we had to add a Outbound Firewall rule (Mappings) from LAN interface (Source IP VPN Client subnet) to the LAN. Now it works!screenshot01l.JPG