@Jamil-Mungur and how was that exactly.. The dyndns was only updating once a day, or every 12 hours or something and the IP from your isp was changing at 7pm? Pretty sure the default in pfsense is to update dyndns on IP change.. Was the ttl on the dyndns too long?

@Elyot Why would you reset the appliance? You should be able to configure it for your needs based on what you actually have. The linked thread shows you, how to route upstream traffic to a certain gateway. This seems to be, what you need here. When you set up a VPN, you can decide if you want to use it as default gateway or not. Most VPN providers pushes the default gateway to the client. That means, any upstream traffic is routed over the VPN. The mentioned policy routing in the other thread gives you an option to direct traffic to another gateway than the default one. If your default gateway is the VPN you can direct certain or all incoming traffic on an interface to the WAN gateway. If your default gateway is the WAN you can direct traffic to the VPN with it. If you don't want the VPN to be your default gateway go to the OpenVPN client settings and add a check at "Don't pull routes".

@Summer You resolved this is problem? I have the problem too...

@viragomann I would call the Ubiquiti/EdgeOS at least a mid-tier product. My opinion aside, this seems to have worked. I can send you a gift card? Thanks

@mstanding said in DNS server push for OpenVPN split tunnelling: I mean we add the company DNS server address into the DNS server settings for the split tunnelling You have to provide it in the OpenVPN server settings: [image: 1693402500588-e0d58fb2-0691-40b3-a548-8ef82d4e429d-grafik.png] it doesn't get advertised to the clients. And on the client: [image: 1693402607241-65ade91a-acaa-432d-b526-1d6cbe239dff-grafik.png] If this doesn't work, check the clients OpenVPN log for hints on what's wrong.

@unique24 Yes, you configure that in the server settings under Advanced Client Settings.

@Gertjan said in Ovpn Remote Access Openvpncpnnect Android: So you use the DNS of pfSense, the one you've set up in the OpenVPN server ? Yes @Gertjan said in Ovpn Remote Access Openvpncpnnect Android: You use a browser that doesn't over ride your DNS ? It seems that is not happening as same behavior can be replicated with Windows 10 client. I've tried layer 2 tunnel and works fine for windows, now need to understand what's happening inside Layer3 as some service works and other will not work.

@Bohodir Hi, Ok, I will try it on another Pfsense. Now, I downgrade to 2.6 to avoid any problems with this update..., waiting netgate make actions to correct it... I use User Auth + TLS/SSL on my configuration Thanks

@BFost said in Looking for ideas on troubleshooting an OpenVPN file transfer speed problem.: is getting 60-70ms latency which seems totally fine to me You understand with that latency, your 8mbps is right in the ball part for a window size of 64k.. So you really need to look what is going on. [image: 1693163421159-math.jpg] I take it they are downloading, and not uploading - because upload they have a max of 10 per their isp anyway.. Are they on wifi.. We have lots of users report bad vpn performance - they were just on a shit wifi connection. If they plugged in a wire, no issue with their performance.

@gui-teixeira101 said in OPENVPN CLIENT TCP CONNECTION: Thanks, Hi, When I search on forum with same topics, I think there is a real problem with last update... So complicated to work with the last version... Someone of netgate team have an answer for it please ?

@bp81 I believe I solved my own problem. Posting the solution here for anyone else who may encounter a similar problem in the future. It occurred to me that each VPN server at HQ defined a separate tunnel network. Upon further examination, there were no routing table entries on the router at HQ to move traffic from the tunnel network for branch 1 to the tunnel network for branch 2, and vice versa. Tunnel network for branch 1 is 172.31.4.0/24. For branch 2 its 172.31.8.0/24 For both servers defined at HQ, in IPv4 local networks, I put in an additional entry. 172.31.0.0/16. This subnet covers all possible tunnel networks I might define that start with 172.31.X.X. This resolved the issue. Traffic can now move from branch 1, to hq, to branch 2 vice versa without issue. I do not know for sure if this solution is "proper", but I do know that it works and it does this by creating the needed routing table entries to move traffic from one tunnel network to another. This was never an issue when I had a single server with many clients, because all clients existed in a single tunnel network, but when you have one client to one server, they all have separate tunnel networks, making the extra routing entries a necessity. The only reason I bothered with this is to use DCO, and it does make a big difference for our offsite backups, so it was worth the trouble.

@viragomann Thanks for your help ... it work! The problem was, that Kaspersky blocked it. after disable kaspersky it also blocked it... i had to go to the firewall port settings and allow it manual. Only deaktivating Kaspersky its not working!

ok thanks

@viragomann it's working without advanced options. thank you!