I have no DNS set up on the VPN server.
I searched the internet for a long time and found this series of commands that solved the problem,I hope it works for you too.
Greetings

@profit said in Where's my Mapped Network DRIVE!?:

@jknott yes, I can ping, but nothing else.

Well, fire up Wireshark (or Packet Capture if you must) to see what's happening. Once we know what's happening to the packets, we're in a better position to advise.

Thanks Jimp for the update, I will work on this project, thanks!!!

I wouldn't worry about it. Any Internet-facing port that's opened is going to be continually "under attack." But that's largely why things like OpenVPN exist. If you're getting these connection attempts non-stop, then yes I might worry that you are being specifically targeted. But odds are it's just the constant, random scanning for open ports with unsecured services behind them. I run an OpenVPN server on pfSense too and get connection attempts like these relatively frequently too.

@derelict said in Routing OpenVPN not working:

Not sure what you want when you're using an ancient version like 2.1.5. Not a lot of people want to spend time chasing long-fixed bugs and problems. You should consider upgrading and seeing if the issue is fixed.

I wrote earlyer, upgrade is in my plans, but NOW I can't do it so fast, so I need solve this question.
I understand your answer, thanks

No. But you can set your OpenVPN server to authenticate against the LDAP or RADIUS server of your choice.

@derelict Had nothing to do with SoftEtherVPN and moreso to do with the underlying SSL package they were using. That said, I do now see how old this is. That part of your comment was at least somewhat helpful.

Hah, nevermind, rebooted pfsense, fixed...

first, it's port 5060 not 560.

Second, I could not get that server to respond. It came right up using this:

# Cryptostorm.is config optimized for Tunnelblick/Viscosity OSX and OpenVPN iOS client dev tun resolv-retry 16 nobind float #txqueuelen 686 remote-random remote linux-cryptofree.cryptostorm.net 443 udp remote linux-cryptofree.cryptostorm.org 443 udp remote linux-cryptofree.cryptokens.ca 443 udp remote linux-cryptofree.cstorm.pw 443 udp remote linux-cryptofree.cryptostorm.nu 443 udp comp-lzo down-pre allow-pull-fqdn explicit-exit-notify 3 hand-window 37 mssfix 1400 auth-user-pass <ca> -----BEGIN CERTIFICATE----- MIIFIDCCBAigAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMCAXDTE3MTIxNjA3 NTk0MloYDzIwNjcxMjE2MDc1OTQyWjCBujELMAkGA1UEBhMCQ0ExCzAJBgNVBAgT AlFDMREwDwYDVQQHEwhNb250cmVhbDE2MDQGA1UEChQtS2F0YW5hIEhvbGRpbmdz IExpbWl0ZSAvICBjcnlwdG9zdG9ybV9kYXJrbmV0MREwDwYDVQQLEwhUZWNoIE9w czEXMBUGA1UEAxQOY3J5cHRvc3Rvcm1faXMxJzAlBgkqhkiG9w0BCQEWGGNlcnRh ZG1pbkBjcnlwdG9zdG9ybS5pczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMlo5Jghf+yb7j86QKDIA9gH9U+MOj1gFz7POcobF3UXx8CR6py4+kY0LEwE s66YuwF3Et1Haymkrxy72RjHqD58FRC1KGg6PzhDr6foXgOpuOweUvBTLS6WR5Ba TW+8oqSkFWIZUWxnk4N1npxonZRjYLjU4AJNB1uUKpp5uwtC+n9UYpNZ2H1SwZDc tpJNzG3Q+ySqkaJYRR44YbeYoTQpbK/G3o7H2Kz1BsNck5h2SVBo9f3JS4gjTcaP fGb6+Lqra/MPlXKY55MzKTLsZ5q1t3ZTjn0vDO7+D7xXoRCXyq9atcRJf9ldm80b xABw5dTiS00E6hm3CzpPOSelAXcCAwEAAaOCASMwggEfMAwGA1UdEwQFMAMBAf8w HQYDVR0OBBYEFDhY4fdfMy+L0fMdat75Kep6cFElMIHvBgNVHSMEgecwgeSAFDhY 4fdfMy+L0fMdat75Kep6cFEloYHApIG9MIG6MQswCQYDVQQGEwJDQTELMAkGA1UE CBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGlu Z3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2gg T3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUGCSqGSIb3DQEJARYYY2Vy dGFkbWluQGNyeXB0b3N0b3JtLmlzggkAp6SkZfFe+FswDQYJKoZIhvcNAQELBQAD ggEBABrPLmFpugICgUKyJ+6q5h8ZKfoV3S0RtTfrwtobNSFf7H4ZQvCXF2bOuhyc g00ffreEGZN2uwtiLh38ncB/BFhHfgkITfTe88m08pJ45PkrpeBfrFbZ+ckXVhV/ aCnUKkIZgmCNKnn1RIbUt4mzTzggwtN3GamoTzSWqSwCEO9Ig1AJKi5Ms/5Awtdz nr95qaqI0ih0NGnfC/yIGYvt1Yay0hCil3jIUT9Ogdw6DW6RqUdJaPrwm58fTwIR U33KzBqGs8r3UEIMWXuIGc6eXOm2Br08iFgOsUPGqp1ulvD52pFH1o1vT21v3aXl D9Ier/83JLMnBGctT1Kzs9OP/U0= -----END CERTIFICATE----- </ca> ns-cert-type server auth SHA512 cipher AES-256-CBC replay-window 128 30 tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA tls-client key-method 2 # uncomment the line below to enable TrackerSmacker, # our DNS-based intrusive ad/tracker blocking service #dhcp-option DNS 10.31.33.7

@derelict Thanks for the tip! My problem was not having the 10.55.248.0/24 on the local and remote networks. I had the spoke subnets in the remote access server. Much appreciated!

switch to aes-128-gcm

One can however connect multiple times to the management interface.
How to connect, see here:
https://forum.netgate.com/topic/122172/kill-ovpn-client-connection

Does that mean the CERDISP Host needs to be connected to the VPN?

the device is a dumb pad that we use CERDISP to display data to a HMI this is now a remote laptop off site.

I added the client override logged into the vpn and tried to display the data onto the host of 192.168.100.106. 192.168.100.0/24 is added to the remote network.

Does the pad just send the traffic to the firewall and it sees it's a 192.168.100.0 subnet and forwards the traffic to the VPN Server?

@jimp I don't know how, but I got the same results even with -p1
0_1534975581300_c3150dac-c7bd-4925-821e-8b5ce90e73cf-image.png

No your not close ;) So your forgetting the opt2 idea.. You don't have a network setup on it even.

Why are you using manual outbound nat and not hybrid?

Your rule to send out your vpn gateway - the source needs to be the IP on your lan that you want to use the gateway.. not your vpn net..

As to pulling routes - you have it check in your vpn client NOT to pull routes... Your sayng your current lan is not using your vpn..

Thanks. Will definitely give that a try. When I look up my IP address while connecting through the VPN, it lists my home cable modem's IP address. How can I ensure that ALL (I mean everything) is going through the VPN?

Thanks jimp. Grabbing the latest build solved the problem. Thanks for your help!

That's all great but this is not edgerouter support.

It appears the pfSense side is fine but the edgerouter is not routing traffic for 192.168.101.0/24 back over the tunnel.

That said, try adding an OpenVPN option on the edgerouter that results in this:

"--route 192.168.101.0 255.255.255.0"

edit -

Probably not since the zebra route is in the table to the correct tunnel it must be getting that from somewhere else. Probably have to ask them.

Thanks

Yep, that's been going around for the last week or so. We have disabled compression by default for new OpenVPN instances on 2.4.4. The good news is that it depends not only on compression being enabled, but also on the attacker being able to get the user to load plaintext they can predict (e.g. HTTP sites), and even then it can only get access to a little bit of data there like session info, and even then only on certain browsers (it doesn't work against Chrome). So it's a clever attack using classic TLS issues with compression, but the sky isn't exactly falling for most people.

https://www.netgate.com/docs/pfsense/releases/2-4-4-new-features-and-changes.html https://redmine.pfsense.org/issues/8788 https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/Nafeez/