Are the certificates+keys password protected? If not, you can't import them without removing that password.

That said, you do not need to import user certificates to use them. They won't be usable with the export package, but they are still valid for VPN Access so long as they validate against the CA as they should, and provided they are not on an active CRL.

@deepak11:

Hi guys,
I'm also having the same problem,
and also I tried adding push route in "Advanced Configuration". its not working.
any other suggessions ?

deepak11, this is a 4.5 year old thread, you should start a new thread with your specific details in it, so we can offer targeted troubleshooting.

At a high level, two things are needed:

On site A's remote access config, push a route to site B's LAN to your clients

On Site B's site-to-site config, add a return route to site A's remote access tunnel network

This can all be done in the GUI now

Thanks!, I found all the certificates including the CA cert and private key. Just to add some information, this post https://forum.pfsense.org/index.php?topic=32372.0 help me get the string of this certificates from the base64 encoded xml fields.

@jimp:

@iesjg.tic:

Same problem here. Set up two instances with the same certs (for client access, not site-to-site) and only the first one appears in the dropdown. Reinstalled the client export package, same thing, only the first one shows

Any ideas?

Check the mode, as mentioned a few posts above. If it does not show in the list, it must not be set to a remote access mode.

You're right! Just set "Remote Access (SSL/TLS)" server mode and showed up!

Thanks!!

Thank you both so much for the clues!  I edited the existing rule created by the wizard on WAN, changing to protocol from "any" to "tcp" and that fixed it up.

Really appreciate the help.

Found it!  I a Zxyel Zywall 110 and I forgot that I needed to add a dedicated routing setup after setting up the new IPSec connection.

Thanks!

The thing is, it works on the Network 1; and route on pfsense is here, and route is on computer too, but don't work on OpenVPN connection

Yep the client-connect script sounds ideal, need to test it on test unit to see what variables you can see will revert back.

Okay, well it sounds like you're set.  Policy routing is just using firewall rules to assign certain traffic to certain gateways and other traffic to other gateways (at least that's my high level understanding of it).  The alternative would be to be to assign traffic to gateways via static routes.  In any case, if you're set up with VLANs I trust you know what you're doing :)

So in fact you only need two VLANs? Or is that just an example?

If it really is only two you can just use two OpenVPN TAP tunnels on different ports. Bridge them to the VLAN interfaces at each end.

That actually helps throughput in most cases by using two OpenVPN processes.

Steve

So I don't know how or why, but recreating the client seems to have fixed this.

Not sure why I didn't try this earlier.

For some context though, the raw interface socket changed. The original interface was being labeled as OPT9 but when I recreated the client it now is branded as OPT1.

At a guess I was creating the client before I had finished something else VLAN related and the OPT interface was mislabelled or misassigned somehow and that is why traffic flow and routing was broken.

Thanks for the tip viragomman!

The only workaround would be to check "Don't pull routes" in the client settings and direct your traffic by policy routing to the vpn server.
So the default route points to the WAN gateway, which is used by pfSense for upstream traffic.

thanks viragomann! i went with your 2nd suggestion of adding routes to each device I needed to access. routing is performed by proxmox host and i don't trust myself yet with attempting suggestion #1 since this is a production environment although it seems like the best way to go about it. thanks again.

a) I have not created any iroutes anywhere (mentioned inthe guide I was following but didn't understand them)

If you are running an SSL/TLS server with a tunnel network larger than a /30 and have routed subnets and no iroutes it is not going to work.

Add the remote networks for each CN to a client specific override.

Thank you  8)

I got this error on a UDP too where I have a mis match in cipher, server was none and client was AES-128-CBC and a mismatch in the comp-lzo, server said no and client was comp-lzo.

Are you using the built-in bsnmpd or the net-snmp package?

net-snmp appears to have counter64 data for ovpn interfaces.

$ snmpwalk bill ifName            IF-MIB::ifName.1 = STRING: vmx0 IF-MIB::ifName.2 = STRING: vmx1 IF-MIB::ifName.3 = STRING: vmx2 IF-MIB::ifName.4 = STRING: lo0 IF-MIB::ifName.5 = STRING: enc0 IF-MIB::ifName.6 = STRING: pflog0 IF-MIB::ifName.7 = STRING: pfsync0 IF-MIB::ifName.8 = STRING: gif0 IF-MIB::ifName.9 = STRING: ovpns2 IF-MIB::ifName.10 = STRING: ovpns4 IF-MIB::ifName.11 = STRING: ovpns1 $ snmpwalk bill ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 206324779 IF-MIB::ifHCInOctets.2 = Counter64: 1245848 IF-MIB::ifHCInOctets.3 = Counter64: 0 IF-MIB::ifHCInOctets.4 = Counter64: 3667209 IF-MIB::ifHCInOctets.5 = Counter64: 0 IF-MIB::ifHCInOctets.6 = Counter64: 0 IF-MIB::ifHCInOctets.7 = Counter64: 0 IF-MIB::ifHCInOctets.8 = Counter64: 8469397 IF-MIB::ifHCInOctets.9 = Counter64: 8510755 IF-MIB::ifHCInOctets.10 = Counter64: 0 IF-MIB::ifHCInOctets.11 = Counter64: 0 $ snmpwalk bill ifInOctets IF-MIB::ifInOctets.1 = Counter32: 206350521 IF-MIB::ifInOctets.2 = Counter32: 1246200 IF-MIB::ifInOctets.3 = Counter32: 0 IF-MIB::ifInOctets.4 = Counter32: 3667209 IF-MIB::ifInOctets.5 = Counter32: 0 IF-MIB::ifInOctets.6 = Counter32: 0 IF-MIB::ifInOctets.7 = Counter32: 0 IF-MIB::ifInOctets.8 = Counter32: 8470213 IF-MIB::ifInOctets.9 = Counter32: 8511571 IF-MIB::ifInOctets.10 = Counter32: 0 IF-MIB::ifInOctets.11 = Counter32: 0

Index 9 is the one to look at.

If you don't need anything from the pf MIB then you are probably better off using the NET-SNMP package.

Installed 2.3.5.  Restored backup.  Ran the same battery of speed tests.  Instant improvement!

Speed's are still nothing like my non-vpn,  but that's as expected.  I got 50-80 Mbps on all the test sites that should be VPN.  Ironically, speedtest.net which the other day was showing my comcast IP but testing super slow, is now showing my vpn IP, but testing at 276 Mbps.  Oh well, at least I'm getting workable speeds through the vpn.

Definitely are some different settings for OpenVPN in 2.4.2 vs 2.3.5.  Even though I set them per the guides, apparently something wasn't agreeing with my system.

I think I'll stick with 2.3.5 until I see a real reason to upgrade.

Yes. It is possible.

Remote Access Server:

https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

Policy-routed OpenVPN Client:

https://www.infotechwerx.com/blog/Creating-pfSense-Connection-VPNBook

VPNbook used there but any provider would work.