Thanks for the help. With this and a guide i found on the forums here after a bit of searching i have been able to accomplish what i was after. Cheers.

OpenVPN clients should go to internet via their own default gateway. Upstream traffic shouldn't be routed over the VPN, but only traffic destined for internal addresses. You should know, which network are to be routed to the head office. If you have host names which you need access to use nslookup or dig to resolve them.

@aagaag Sorry, never with pfsense, although I did find a tutorial that stated it could be used with Tomato, which gave me some hope. Two links, both very similar: https://www.safervpn.com/support/articles/115001428485-Manual-L2TP-Setup-for-Tomato-Router https://www.limevpn.com/how-to-use/tomato-routers-l2tpip-sec-setup-instructions/ This didn't work for me, because I have a Static IP (over PPPoE). The setup requires the main (WAN) internet connection to be setup as L2TP. Sounded logical (from a newbie perspective) but improbable (with a little knowledge). Since both links are from the relevant support teams of VPN providers, maybe it does work, and these similar settings could be applied to pfsense? http://pfsense.local/interfaces.php?if=wan offers an IPv4 Configuration Type option of L2TP. If I had a 2nd WAN, I would try it, but think it may also fail if your connection is PPPoE? Maybe the gurus can help explain (but keep it simple, please?) Many thanks.

I had a similar problem during my migration from Tomato to pfsense. Turned out this was due to multiple Default Routes in the Routing Table. All fixed with the help of @johnpoz. You might want to check that?

Thanks viragomann. I've forgot to add 10.0.2.0/24 on the site-to-site server. It works now, thanks!!

Same here cant configure bridge interface no matter what i do.

Make sure the VPN gateways have "Disable Gateway Monitoring Action" ticked as if the VPN goes down with that enabled it can cause all connections to constantly bounce causing a loss of connectivity.

Thanks very much I will take a look at those!

a service .... that needs admin privs to install

Ok, final update. Eliminated everything that had to do with this VPN, interface, rules, etc. Started all over, following all the steps, and everything is working as it should, without the manual routes. By the way, if you run into the routing problem, you can change the "Gateway creation" to BOTH or to IPv4 ONLY and apply/save ont both server and client side(!) That creates the new route. Thanks all for your time and effort

np glad you got it sorted.

@jimp I'm doing rds through vpn no there is only one traffic on port 1194 i have 2 wan so in case one crash the other takes over the same port vpn a sdsl and an adsl

Thanks a lot Jim. That worked !!!

Is there a firewall rule on the OpenVPN interface which allow the access? For communication between clients check "Inter-client communication" in the server settings.

If multiple clients connect to the server you cannot make use of policy routing in filter rules. But it's possible to route some destination networks to a client. However, this is applied to the hole network. If you want to do that, you have to add a client specific override for the concerned client to set the routes. Add the networks you want to route to the client to the "Remote Networks" in CSO. CSO only works with SSL auth, cause it is based on the common name in the client certificate. If you are running multiple OpenVPN instances additionally assign an interface to that vpn server.

Thank you, You steered me in the right direction to double check all my routes. I fixed the problem by replacing push "route 10.0.9.0 255.255.255.0" with route 10.0.9.0 255.255.255.0 on Site-To-Site connection server side. I guess I put it there by mistake. For anyone readying this in the future here are additional steps to make this work: Site-to-Site: server side: add route 10.0.9.0 255.255.255.0 to "Custom options" field client side: add 10.0.9.0/24 to "IPv4 Remote network " field (in addition to 192.168.1.0/24) Remote access: server side: add push "route 10.10.0.0 255.255.255.0" --> will probably work without this if you route all traffic via this tunnel from the client.

@sasansgh said in Question about Virtual Address: But why do we need a virtual IP? Why not just use the public IP assigned by the ISP? When a computer on your network has a packet to send to the device at the other end of a VPN, it will send it to the router (pfSense), which will in turn forward it to the destination via the appropriate route. If you use the public IP, the router will send it out the WAN port, instead of the VPN. By providing addresses for both ends of the VPN, the router can determine the packet has to travel via the VPN and use the tunnel addresses to do that.

Hi Johnpoz Do you get any solution for me?