@Alessio-Zatta said in Package installer failed (openvpn-export): So its running on an old PC That was my initial pfSense experience ! A desktop PC has a build in NIC, so add one more and you're good. Still today, you should make use of some common knowledge : Make live easy on yourself. So, these are "the rules" : If the motherboard has Realtek chipset : pay it a visit in the PC's bios, and select Realtek's most useful option : set it to "Off". Disable it. You just raised the chance of having a perfect "home build router" experience by a lot. Next rule : No, don't take that USB to NIC adapter. Don't fall into that trap. Do what needs to be done : get that one or dual Intel NIC, and slap in in your PC. If you're above average, you check upfront that the card you buy is supported by "FreeBSD". If the card is Intel branded, you'll be good. Using these rules and pfSense is up on running in .... 5 minutes ? Later on, you can always activate the Realtek NIC again, and see if it plays nicely. Not all of them are bad. And again : Wile installing pfSense, you have to assign networks, as a router needs a WAN and a LAN. You also have to create your own password. And here it comes : if you use or see a wizard that talks about 'DNS' do not touch your keyboard. Use the mouse, if possible, and enter nothing. Just click on 'Next'. Next has been chosen by Netgate as the perfect DNS setting. pfSense will work out of the box. Up can now see the available package list. and install what you want. And as "realtek", later on, you can adapt your DNS settings if you want to. "It will break" but now you can "step back" and it works again. After the wtf phase, the conclusions that you will make at that moment are very important.

I managed to mitigate this somewhat by changing the configuration of the offending interface to static address assignment. That didn't prevent it from going down, but it did at least keep OpenVPN tunnels not bound to that interface from needing a restart. The WAN interface in question is passed through from an AT&T residential fiber gateway / ONT. It's an Intel I-225 for what that's worth. I'm not convinced the interface isn't at fault, so I switched over from the igc0 interface to a vlan on my main NIC, which is ix0. That wastes a NBASE-T switch port but works ok so far.

@McMurphy said in Client Specific Overrides Security: but if all users on on the same VPN server how best to differentiate between users to firewall some and not others? With firewall rules. In the CSO you can state a unique virtual IP (tunnel network) for each client. Then you can use this in firewall rules as source to allow certain accesses.

@slu OK, thanks for the suggestions, I will investigate when user is available.

I just also found it on the Tunnelblick website. https://tunnelblick.net/cTunnelblick4.html

@viragomann Thank you. Long day and was not thinking. I was thinking outbound traffic was on port 1194

@labu73 pfSense uses the reply-to tag to route response traffic to public sources back to a non-default gateway. Otherwise it would be routed out on WAN. The reply-to tag is added by the filter rule, which allows the incoming request packets. So this rule has to be defined on an unique interface. However, OpenVPN is an interface group including all OpenVPN instances, which are running on pfSense AND rule on interface groups as well as floating rules have precedence over rules on member interfaces. That's why this rule got hits, while the rule in the interface didn't.

@tman222 I don't expect, that any Radius traffic going out of pfSense. I don't use it, but as I understand it, it's just a local authentication server. So if the reply-to tags are applied properly to the VPN connection, I'd expect it to work.

@pyite You can revoke the client certificate to prevent using it to connect. To do so, you have to create revocation lists for the used CAs in System > Certificates > Revocation, as long as you didn't this already. Then assign it your VPN servers.

The reason was (a), the username was not matching Common Name. One needs to enable "Username as Common Name" for the server for this to work properly.

If you don't know a remote source beforehand you can't firewall it in advance. My approach would be to make sure you're using TLS keys in addition to client certificates and also usernames and passwords. That's three levels of authentication where if any one of them is not present, the connection won't establish. Yes, you can use the cloud provider approach but then you're relying on your connections first establishing to that provider and then to you. All that is doing IMO is moving the "noise" elsewhere. I'd just use good security and live with the noise. TLS key, client certificate (which can be revoked), associated private key are something the user has. The username and password are something the user knows. That's not terrible in my book. edit: you can also cut down on the noise by using a different port on the server. The usual port of 1194 UDP is going to get probed a lot. Pick something else and you'll likely have less noise in your logging. second edit: the response about using dynamic DNS didn't make any sense to me at first as I was thinking of this as supporting a fleet of remote users but that could work. However, I tend not to trust dns resolution in critical aliases as I've seen empty alias tables too many times.

@djlandino If you want to be able determine the clients on the destination devices by their virtual VPN IP, you have to connect the VPN box to a separated network setment, a transit network, to get the routing work properly.

@viragomann I'm trying to still with the traffic over the VPN tunnel and don't expose the syncthing encrypted traffic trough the internet, that way don't need to NAT any ports on remote touter. I will check how to set up VPN as private network I don't have any idea but i will investigate Thanks

@Pippin that common subnet list is excellent!

@viragomann OK, so this issue is resolved. I disabled ALL the other P2 proposals under the corresponding P1 (the reorder function in the UI crashed?!) And now I can see traffic flowing from a host on the LAN subnet to the host at SiteB and from the OpenVPN client to the same host on SiteB. They are both using the same BINAT network range for NAT, which is a non issue in this test setup but could cause issues where the last octet of a client is the same in both P2's. I suspect the issue was the ordering of the P2 proposals, it's the only change I made. Thanks for pointing me down the right path!! [image: 1709814557722-591ec58a-5e86-4b6f-a4b0-e619692ca83b-image.png]

@ariban99 You were missing the clients tunnel IP in the CSO. Note that a tunnel network of /30 or less is not compatible with DCO (only supported on Plus at this time, but I cannot see, which version you're using).

I fixed on my own. I am not sure why but the default "Camera Subnets" was somehow not correct. I created a new Alias with the Camera Subnet defined properly, then applied it to the Firewall Rule and the Nat Rule for the Camera Subnet section, and it worked. I also added the kill switch with tagging which is defined in this video. Which for anyone having trouble, this was the best thing I found in all my searching. https://forums.lawrencesystems.com/t/how-to-setup-pfsense-openvpn-policy-routing-with-kill-switch-using-a-privacy-vpn-youtube-release/12441