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 [image: 1534975555817-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/

In case this will help any one else, I've figured this out.... Here is a link on how to find the logs for NPS... https://social.technet.microsoft.com/Forums/windows/en-US/45aa3000-c32b-483b-8d6e-565b56b163fc/how-to-check-the-nps-logs-in-the-event-viewer?forum=winserverNAP Basically there are text file logs in c:\Windows\System32\LogFiles\In* , or you can check in Event Viewer under Diagnostics -> Event Viewer -> Custom Views -> Server Roles -> Network Policy. In my case, the problem users were set to "Deny Access" under the "Dial In" tab of the user properties in AD Users & Computers. Setting to Allow Access fixed it up. If you don't see the "Dial In" tab, this may be of help : https://support.microsoft.com/en-ca/help/975448/the-dial-in-tab-is-not-available-in-the-active-directory-users-and-com For me, I had to be on the server to get that tab, not accessing Active Directory Users and Computers on another PC. Hope this will help someone else. Thanks, Derelict for pointing me in the right direction!

I've just successfully troubleshot a 2nd extension today: Depending on your OpenVPN connection (all traffic, DNS etc) you may want to change your PBX hostname in the SIP client from FQDN to LAN IP, and make sure that all Local networks are listed in the appropriate sip.conf file.

@pnunn The default route is simply the way out of the network. It's just like driving somewhere. The first thing you have to do is get out of your driveway. On more complex networks there may be other, more specific routes that might be used first, but eventually you'll need a default route. The only exception is at the top level, between ISPs, carriers, etc., where every possible route must be known and the packet gets dropped if there isn't a route. You could route through an interface, but only on point to point links. On Ethernet, there's always the possibility of more than one other NIC out there, so you can't rely on using just the interface.

@viragomann maybe I screwed up then. I had a root CA, and under that I had two intermediate CAs, one for each OVPN. They were both able to log in. I'll try making two root CAs.

@andrewz I did that allready.

That is automatic if the OpenVPN server is bound to the CARP VIP. If it is not doing that you have something wrong. What that something is could be anything based on the information given. What would probably be telling are the OpenVPN logs from both nodes during a failover and failback. Maybe the system logs.

@nikkon How do I disable suricata?

Thank a lot for replies Is there a way to make it shorter than 60-sec ? Any setting to adjust ?

Yes. The modem/edge router will need a static route pointing the VPN client subnet back to pfSense When there is only one interface it is WAN That's a bit vague, but in general you'll still need a few things. pfSense will have to use the modem for its default gateway, you'll need firewall rules on pfSense to pass the VPN traffic in WAN and OpenVPN tab rules to pass VPN traffic in there.

@jimp said in OpenVPN Client dropping every second state: Also "OpenVPN" is an interface group not an interface, so using it as a NAT destination may not always do what you expect, especially for outbound NAT since it would effectively round-robin in that way for outbound. Yeah I didn't realise it would round robin like that but now I do. @derelict said in OpenVPN Client dropping every second state: 10.1.70.0/24 still looks wrong. I removed that em0.70 interface and configured the server properly, Now that route isn't there which is good.

@derelict said in Problem with OpenVPN Client Export: That's not correct. Use your own PKI. Thank you for your reply. No no, I am using my own keys. The problem were COMODO keys actually. Everything works perfect now. Thank you for all your support .