Your tunnel networks need to be in the same subnet 172.27.224.0/30 would work for both of them.

I realize that this is an old post, but I couldn't find the answer to the Interface Group order anywhere in the forums. Using /tmp/rules.debug. I found that manually created Interface Groups come before OpenVPN rules. I also found that if you have multiple interface groups then they are processed in alphabetical order. I have three Interface groups: Local for all my local subnets, Clients for local client subnets, and IoT for local IoT subnets. They were processed in the following order: Clients, IoT, Local. When I renamed Local to All_LAN and made a minor change to the rules so they were rewritten, the order changed to All_LAN, Clients, IoT, which is the order I wanted. I realize I probably don't need so many subnets, but using Interface groups and RADIUS to assign VLANs made it easy to setup. I have a VLAN for each person in my household in Clients Interface Group and my IoT devices are in different VLANs by type. It was simple using FreeRADIUS. Thanks

Hello Yes all is working, after some rechearch i found something concerning virus protection. But now my problem is : i have to disable my bitdefender firewall to access to my network. Someone know how to enable the btdefender firewall and add an exception ? Thank a lot

Problem solved. I 'm so sorry to be so stupid i was focus on my local network and forgot the client configuration and change the ip --' I put my public ip and all work fine now. Thank a lot all for your help. Have a great day (i't my bithday today :p = 30yo)

By the way, tap mode changes almost nothing in the scenario. The only difference is that the tunnel network is no longer point-to-point and has broadcast semantics resembling a typical ethernet LAN. Client configuration and routing are still pretty much the same and if you can't get tun mode working properly you won't get tap mode working either.

I would like this feature, too.

Hmm, yes indeed.

Well your authentication retry checkbox would have nothing to do with that.

on pfSense which is the server and the DDWRT is the client you need to add this part on the pfSense client override ifconfig-push 192.168.90.5 192.168.90.6 iroute 192.168.1.0 255.255.255.0 192.168.90.5/24 is my openvpn server and the 192.168.1.0/24 is my LAN which is behind pfSense change the IP depending to your config

Thank you. That explains things perfectly.

@oguruma I don't know what would be causing that. Is the packet loss on the VPN client interface(s) only? It would be even more confusing if establishing a VPN client connection provoked packet loss on your WAN interface. Also, have you tried specifying different monitor IPs for your VPN client interface(s)? I use Google and Cloudflare DNS servers (e.g. 8.8.8.8, 1.1.1.1).

Multicast isn't going to cross a VPN tunnel like that. Typically the solution would be to make a tap VPN and bridge that to your LAN, but last I knew, iOS did not support tap mode for OpenVPN.

@gcu_greyarea said in TLS 1.0 but need TLS 1.2 for OpenVPN with Yealink Phone: tls-version-max 1.0 Just FYI... I tried custom option “tls-version-max 1.0” on my VPNServer (on pfSense) and the server actually honours that option. I tested with the iOS OpenVPN APP which gave me a "Server Version too low" error. After changing the Minimum TLS Version in the IOS App to "TLS 1.0" I could successfully connect again. The question is whether the Yeahlink Phones (with new firmware) are capable to negotiate down to TLS 1.0 automatically. Alternatively - if you have hundreds of Yeahlink Phones you may have enough leverage to ask Yeahlink for a custom patch. I.e. the same firmware which defaults to “tls-version-max 1.0”. However that doesn't really fix the compatibility issue..... Might also make sense to have a look at the supported ciphers on the phone?

https://www.privateinternetaccess.com/pages/client-support/ its under advanced SSL usage. use the new openvpn files under OpenVPN Configuration Files (Strong) either way thats awesome its backup and running. i also use cloudfare as dns for my devices outside the vpn tunnel

I have no problem getting DNS IPs to Linux or Windows..

You could do some outbound NAT on the OpenVPN connection to nudge that, but you're better off letting it route naturally if you can. Maybe add a route to the DNS server's gateway nudging that traffic back toward pfSense.