Yes, that is clear to me now. I got confused by two things: 1. In CSO "NOTE: Remember to add these subnets to the IPv4 Remote Networks list on the corresponding OpenVPN server settings." 2. In Server "Inter-client communication" 2 should not be ticked as one cannot control "who can see who" if ticked.

Hello! Thank you for the reply, I have a dynamic public IP, but I have something similar to DynDNS meaning I have an domain name to my IP (which updates automatically when the IP changes. Best regards Tobias

@firemogle: Really, if I can get port 6881 and 6882 going from VPN to one IP I think I would be set. Thanks again, Are you talking about connections outbound to destination ports 6881 and 6882 or connections from the internet to 6881 and 6882 being forwarded to your host? The latter is trivial. Just make the destination ports on the rules that policy route to the VPN 6881 - 6882 instead of any. I don't know if you need TCP or UDP or both. TCP probably. But I don't think bittorrent works this way. To get ports from the internet forwarded to your host, first PIA has to listen on those ports and know to forward the connections to you. You have to have an OpenVPN assigned interface and port forward those ports to your inside host. Then you have to be sure those ports are allowed into your firewall on OpenVPN assigned interface rules - normal auto-generated by the NAT rule are OK here. If you're talking about making something like the attached show Open, this is what you want.  

Probably so. Especially if that service wants to be < 1024 port. ;)

@Pippin: I know OpenVPN has a built in internal packet filter that would allow firewalling client-to-client connections Here I'm confusing tun and tap. In case of tap above is true. With a pf_plugin_module for OpenVPN one could setup a scheme for who can talk to who. 1. Does allowing "Inter-client communication" in "Servers–>Edit server" set the client-to-client option in server config? 2. If so, then this cannot be firewalled? Yes, I just checked this, it does set client-to-client in server config and to my knowledge it cannot be firewalled. Is that true also for pfSense? If so, then maybe this should be stated under the tick box/help. It would mean, if one wants to firewall client-to-client communication, do not tick this box.

got it working.  turns out for some reason restarting the box once changes applied fixes it.  What i had done was right but reboot need for some reason. Thanks All Mat

Thanks for Pinpin quick reply. I will try that out. Thank you very much.

So, A<->B is SSL and A<->C is shared key, you're running two separate instances of OpenVPN on A? While there's nothing inherently wrong with that (I run many instances of servers and clients on my boxes) is there any reason not to consolidate the connections into a single server on "A"? If you've already "bit the bullet" and setup an SSL instance, I would suggest making both your connections SSL. Even if you need two separate instances, it'd be worth making both SSL IMHO. While getting the routing options to work with Shared Key is possible, I've always found the options more limiting compared to SSL. Pretty much fill in the network lists you need on the Server side, add the CSO's and you're up and running. The other plus would be we don't have to debug two types of connection (that's just me being greedy  ;D  )

I was just monitoring my firewall after a power outage and found this issue. I removed the simple traffic-shaper I recently put in place for VoIP and the CPU usage fell to sensible numbers. I tried putting the shaper back (CBQ) with the wizard but the openvpn usage went back to 100%, so it is not fixed 2.3.1-RELEASE-p5 (amd64)

what application is that is that has to broadcast?  What is the latency between these sites?  I doubt such a crappy application that needs to broadcast is going to work over any sort of latency. So these sites are using the same ip scheme?  Ie you have say 192.168.0/24 on both sides?  Even if you connect them at layer 2, your layer 3 has to be the same. As to your dhcp - the whole point of dhcp relay is to allow for your dhcp servers to be on different layer 2 networks. Here is a thread from 2014 wanting site to site tap - he got it working and there is instructions in there https://forum.pfsense.org/index.php?topic=84419.0

The others could be whatever you want on them..  Be it based on the specific user your creating the cert for, or you site and location.  Email for example could be the users, the admin..  etc..

Sorry, that is the one I was talking about.  I'm not at home so I was going off of my phone configuration as I can't look at my system at the moment. Thanks for the answer.

switch is probably missing a default gateway, or has the wrong default gateway, or the default is on a diff subnet so it's replying back the wrong way.

Unless I've misunderstood your original request, no, you don't need anything like that. This is assuming you're talking about having remote access OpenVPN clients connect to both your WANs and use Multi-WAN for their Internet-bound traffic coming across the VPN: a: Make sure clients can connect to both WANs: 1. Set the Interface for the VPN to Localhost 2. Add port forwards to both WANs to forward your OpenVPN port for this server to localhost (127.0.0.1) on the same port b: Use gateway groups on OpenVPN rules: 1. Firewall > Rules, OpenVPN tab 2. Add a rule at the top of the list to match from a source of this server's tunnel network, destination is your local LAN, without a gateway set 3. Add a rule just under the previous rule to match from a source of this server's tunnel network, destination is "any", using your existing gateway group.