@johnpoz Johnpoz, Hey JohnPoz, I think you're the only one who can help me. I have done a refit of my network with Catalyst 3750 and 4948-10GE. I have a serious DNS problem. I have a few switches/routers that run OSPF, 1 router is connected via a /30 subnet (lag of four ports) to the firewall. All clients behind the ospf routers can reach the pfsense GUI webpage, but they cannot access the internet. Windows 10 diag indicates the DNS server is unavailable. Windows DNS server is configured with the IP address (LAN interface) of the firewall. A null route is configured on the ASBR (0.0.0.0 0.0.0.0 next hop IP) and has been propagated to all ospf switches/routers. In pfsense there is a static route (the lagg link) back to the internal ospf network. So I know that routing works from the client to the edge firewall and vice versa. I have configured a rule that allows the internal network (summary route) to the firewall and for outbound NAT, allows the internal network (summary route) to everything (*). Normally every client should be on the internet, but that doesn't happen, Windows 10 complains about DNS unavailable, I don't understand what is wrong. In pfsense I did a few tests with nslookup in diagnostics for msn.be for example and the output is positive. I do not immediately see an error in the output. Can I assume that DNS resolution works on the firewall? One way to test is to connect a PC in a /30 directly to the LAN port, but the /30 LAN port has a port channel, and I tried one link instead but that didn't work, couldn't connect to the firewall, probably because of the static route which expects another network device, I dont' know. Do you perhaps have some advice?[image: 1708813404380-example.jpg]

@marcelobeckmann Thanks really thankful for this :) will look into it.

@CoffeeOrTea said in OpenVPN Firewall/tun Question: At the time I made this post, I didn't realize that you could assign an interface to OpenVPN. I eventually did, which added a 2nd tab to the firewall rules area, so now I have two OpenVPN tabs in the firewall rules area pfSense show particular interfaces on the rules page in upper-case letters. So I'd expect, that it is rather shown as "OPENVPN" there in addition to OpenVPN, wich is the interface group. if I have no rules at all on the OpenVPN tab, but then add a rule to allow WAN traffic on the OpenVPN interface tab, I don't get WAN access. But if I allow WAN on the OpenVPN tab, then it works. So you presumably did something wrong. OpenVPN is just the interface group and the interface is a member of it. Note that rules on interface groups have priority over ones on member tabs.

Thanks, that seem to solve the issue but feels like a workaround.

@viragomann It works !! Thank you SO MUCH for your precious help... I now need to adjust firewall rules. Thanks again Robert

In the end I turned off NAT reflection for all but the VPN rule. The rest worked fine with the split DNS approach and no NAT reflection. I don't think it is doable to have the android openvpn client requery dns when transitioning networks. Though I guess you could have forwarding rule on the LAN that redirects VPN traffic to the pfsense interface where openvpn server is listening.

@deet said in site-to-site ssl/tls with ospf: I'm moving forward now with a separate OpenVPN tunnel per remote site, each on a /30 point-to-point link. Deprecated or not If you are willing to spin up a new VPN overlay why not just use IPsec. Easier to maintain and run dynamic protocols and there are no deprecation notices.

That was the key clue. A Google search for that line led to another discussion in this forum. The last post in that discussion hinted at adjustment of the compression configuration. When I switched my server’s like this: [image: 1707971705823-screenshot-2024-02-14-at-11.34.21-pm.png] i.e., set the compression to “Refuse any non-stub compression,” I could see my client’s pfSense appliance at 192.168.4.5. Voilà!

@Dyspareunia said in pfSense UI doesn't support inline keys - tls-crypt-v2: tls-crypt-v2 /var/etc/openvpn/client6/tls-crypt-v2 Just wanted to say Thank you for this post. I was not able to add tls-crypt-v2 in the pfsense client creation GUI but with your approach it worked for me

@brianjmc1 Tried the forum search? There are several threads regarding this topic. In the OpenVPN access server settings you have to add 192.168.200.0/24 to the "local networks" to push the route to the clients. And in IPSec you have to add a phase 2 for the OpenVPN tunnel pool and the branch LAN. So in the main office: local network: OpenVPN tunnel network remote: 192.168.200.0/24 And in the branch: local network: 192.168.200.0/24 remote: OpenVPN tunnel network Ensure that the access is allowed on all incoming interfaces.

Guys! I'm seeking you help please

@viragomann appreciate you helping me to troubleshoot anyways!

@rjabellax5 Basically your settings should also work well with pfSense 2.7.2. However, shared key mode will be removed from future OpenVPN versions. So you should consider to move over to SSL/TLS peer-to-peer connections. At this occasion you may also want to update the ciphers to GCM or CHACHA20-POLY1305, depending on your hardware.

@bamypamy said in 2fa with ldap - Active Directory - Freeradius: https://forum.netgate.com/topic/180533/openvpn-freeradius-and-ldap/7 Responder Cotización Yes I saw it, but I also have more than 10 users. It's a shame not to be able to implement this 2FA

@michmoor I checked this option but I also have the problem that it is more than 10 Users. I guess I need to ask for some money. ;-) Thanks for replying.

@jimp Indeed that is a great resource to use for troubleshooting, thanks for sharing it!

@lifeboy Glad you're working now. What I learned on my journey to solve this problem is that there are many different causes that manifest in the same failure signature. The story of my (professional career) life. We were always the lightning rod.

@Rico said in Multiple logins with same user account, concurent connections disabled: You need to check Enforce match (Strict User-CN Matching) in your OpenVPN server settings. -Rico Seems to work, thanks a lot!