I agree with you jimp.  The bad news is openvpn GUIs seem to all suck for me in linux.  The good news is once you figure it out, which isn't hard, vpn in linux is very reliable.  I'd say more than windows.

viettruong, I do not see a question here.  Please clarify what you are trying to do.

If you need the key, then you need to export the key (second export button).  Key blobs don't start with –---BEGIN CERTIFICATE-----  they usually start with -----BEGIN RSA PRIVATE KEY-----

Looked at the link.  Export the p12 (third export button).  If it prompts for a password enter nothing (unfortunately).

@pberis:

Just for clarification, How do you use "Client Specific Overrides" with AD?  Thought I had read somewhere that you had to use local database for CSO … Is this no longer true?

Okay, that was wild guess. I have no experiences with OVPN server in combination with AD. I just use local database, cause we need a fistful users only.

However, if you use TLS the second recommendation should work. It does a good job for me with local user db.

I think there's a basic misunderstanding here:

well, what I can't understand is; why it works only if I disable clients from pfsense gui !! and if I activate them I can just see my vpn clients.
in this exemple and I use the same configuration, agenthex and agentansi (disabled ) connect successfully and ping my internal network, but it's not the case for agentonsa which is connected but can ping only vpn clients.

I would like to share print screen, to show you better my problem, but when I attach files I receive " 500 Internal Server Error ".

OpenVPN: Client

Disabled  Protocol  Server  Description

YES  UDP  41.X.X.X:1194  agenthex       
YES  UDP  41.X.X.X:1194  agentansi       
NO  UDP  41.X.X.X:1194  agentonsa

The diagram you posted earlier shows a central pfSense box controlling LAN 172.16.10.0/24.
You also showed two different clients, one PC based and on Linux based, connecting to the pfSense box via OpenVPN.

In order to make this scenario work, you need only 3 pieces.

An OpenVPN SERVER running on the pfSense box A Windows compatible OpenVPN client running on the Windows box. A Linux compatible client running on the Linux box.

That's it.
There is no need for any OpenVPN client on the pfSense box.
The OpenVPN server on pfSense sits and watches on port 1194 for clients attempting to connect.
The clients on each machine try to connect to the server IP address on port 1194 to get a connection.

The reason it only works when you disable the other "clients" is 1) they're conflicting with the pfSense Server and trying to use the same port (1194) and 2) THEY'RE NOT NEEDED TO MAKE THIS WORK!  (sorry for the rant  :)  )

Seriously, I think you've actually got this working, it's just simpler than you think.

Hi,

I have the same problem.

I created a new certificate and recognized a mistyping in the Name.
Then I deleted it. After I recognized the text in the WebGui of the Certificate Authority Manager:

Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 394 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 444 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 490

Maybe it is, because the name for the Cert. that I wrongly entered, was the same that was already in use?

I can not export any Client or Certificates anymore, like elemay mentioned.

Is there any possibility to get more details where the problem is caused by?

Maybe some one could help me how to fix it.

BR and many thanks indvance.

Give us a network map showing what you're trying to do, so we can help you.

This is a known limitation, huh.

https://doc.pfsense.org/index.php/Multi-WAN_2.0#Policy_Route_Negation

I guess a reasonable practice would be to always define at least a management network in IPv4 Remote Networks on your client so you can get in and add other networks if you have to go Multi-WAN on the client side.

Something like this also seems reasonable and seems to work.  (Screenshots aren't uploading):

IPv4 * LAN net * RFC1918 * * none   Add private destinations to negate for VPN traffic IPv4 * LAN net * * * WANGROUP none   Default allow LAN to any rule

@kejianshi:

Try this - Just list it in "IPV4 local networks" along with the other /24 you have listed there and remove your push command.

I wonder what that would do?

Sorry, would you mind to elaborate? Thanks! :)

Do you have two separate pfSense boxes or one installation with two WAN NICs or one pfSense and something else?  It's not clear from your explanation.
Are these two firewalls actually independent of each other or does one get it's WAN from the other?

Is the pfSense OpenVPN instance the client or the server?

Perhaps a simple diagram would make it easier to understand.

The only thing else I can guess from your description is you may have a description/config issue as you say

So I can connect to the pfsense but cannot ping any devices on the 10.1.52.0/22 network.

but you describe the pfSense LAN as:

LAN: 10.1.53.5 (connected to the main network 10.1.53.0/22 ) No dhcp,

Do you expect a ping from 10.1.52.x to reach 10.1.53.5?
What do your route tables on the OpenVPN connected device look like?

One last sanity check, are you sure the internal LAN device will respond to pings from an external subnet (Win firewalls off, AV disabled, etc.)?

Thanks again divsys, you really saved me lot of time!

I just watched the recent gold hangout with jimp and this very topic was addressed.  I haven't done it and don't really understand it but there's a way to get reply-to working to put the return traffic back over the VPN and not out the default gateway.  The hangout is kind of a deep dive covering a lot so I'm not quite sure exactly what he's talking about…yet.

Got a report from a customer that these installers do work so long as you take "persist-tun" out of the client config.

So… it's not an OpenVPN vulnerability, but it's a potential vector for one.

That's like saying Apache is vulnerable because it can be configured to run scripts that might happen to call bash...

Still not a problem for us, none of our scripts would use bash. :D

(Now if someone manually added bash and added their own scripts, perhaps, but that's not on us...)

What about bridge: server1+server2+lan?