@viragomann It is all working now! Thank you!

@hispeed So I tried this in my lab last night and could not get it working although it should. To be honest, you're wasting your time. Just do a peer to peer with a /31 and be done with it. But if you want to keep trying.... First, you do not need a CSO with only one client connecting. As I said, get rid of it. Not doing any good. Second, with remote access as the type, you're basically creating a "road warrior" vpn. Typically meant for one client to connect to one site. It doesn't enable other clients on the remote network access to the vpn. That's why I say just do the peer to peer as it's meant to be used. But you can configure a remote access for the entire remote LAN, see here: https://community.openvpn.net/openvpn/wiki/HOWTO#IncludingmultiplemachinesontheclientsidewhenusingaroutedVPNdevtun Again, I tried it, it's a waste of time when there's an option made explicitly for what you want. The biggest problem with remote access is the config doesn't give you the option to set "Remote IPv4 Networks" and peer to peer does. By the way, that error you're seeing has to do with the certificates. Did you create all certs on the server, then export the needed certs to the client, or did you create certs on server and create certs on client?

Problem solved for now: The problem was solved when I deleted the VPN server I created and created it again. (VPN>openvpn> servers) Later I realized that; If you add the openVPN interface from the interface section, this problem happens. Even if you delete the related interface later, the problem is not solved. However, when I delete the server from VPN>openVPN and add it again, it is fixed. To everyone thank you

@panpanpramuk What is the goal of the OpenVPN client? A connection to a VPN provider? Did you set up the client accordingly to a guide? Which? Did you do all steps? What is your intention? Do you want to route all traffic over the VPN or only particular?

Solved Adding push "route 10.4.0.0 255.255.255.0" on VPN >> OpenVPN >> Client Specific Overrides >> Origen >> Edit >> Advanced >> ADD push "route 10.4.0.0 255.255.255.0"

Hey guys, figured it out. Talked to a Shaw rep and I had the internet plugged into the wrong ethernet port on the back of the modem. Weird because everything worked but the one port is a dedicated WAN port that i didn't notice. My eyes aren't the same as they used to be, lol..

@viragomann It worked!!!! You Rock!! Thank you very much!!!

@bambos Yes, I agree that it behaves in an other way than expected. Obviously the 'interface net' alias doesn't work with OpenVPN interfaces. If you check Status > Interfaces the site to site OpenVPNs interfaces have a 255.255.255.255 mask. So it only includes the interface IP. And the same is adopted in the rule. Don't know, what's the reason for this behavior.

@johnpoz said in Adding https connection: Running on tcp 443 comes in handy when your at a location that blocks UDP 1194 That's exactly why I'm doing it. Some places, such as the local library, block anything other than browsers. I'm aware of the issues of running TCP on top of TCP. I don't run anything else on 443. The pfSense GUI is plain HTTP on port 80.

@greentea Did you forward the VPN packets on the ISP router? I suspect, that the packets don't reach pfSense WAN interface. To investigate run a packet capture (Diagnostic > Packet capture) on WAN and set the port filter to 1194, while you try a connection from outside.

@viragomann The routing table showed the problem. The VPN site I don't control started using the same IP subnet that I'm using which is causing conflicting routes. Thanks for the idea.

@viragomann Hi - it works but then stops working :( I think its causing some kind of loop somewhere - behaves strangely Regards