@jacobisreal said in OpenVPN clients can't ping LAN: Any suggestions about how to filter internet sites / URLs for users connected via the OpenVPN? If you haven't "Redirect gateway" checked in the OpenVPN server setting internet traffic is not routed to pfSense normally. You have to consider that the users can add routes by themselves, however. So you should add rules to the VPN interface to restrict access for your needs. If you also want to pass internet traffic from the clients over the VPN rules are more complicated. But this depends on your needs. @jacobisreal said in OpenVPN clients can't ping LAN: Also, the automatic .ovpn client config file download? Already talked about that above. There is nothing intended on pfSense. But search the forum, maybe someone has posted a script to aid distributing VPNs.

@behemyth said in What FW Rule do I need to allow users internet access?: How do I allow a client access to the internet when they are connected to the VPN? I have a rule allowing them to hit the DNS servers, but any rule I make allowing the traffic to WAN NET or WAN address all fail. I dont want to put in a default allow rule to allow any traffic anywhere on my network. What am I missing? There are a few different ways to do it: One option: Pass - Tunnel Network/DNS server Alias Block - Tunnel Network/LAN net (or alias for multiple networks) Pass - Tunnel Network/any Another option: Pass - Tunnel Network/DNS server Alias Pass - Tunnel Network/Invert Match LAN net (or alias for multiple networks) Also, considering there's no local access... unless there's a reason you want your clients using your DNS server(s), I would actually remove access to DNS altogether and push them Google DNS.

@steamerzone said in pfSense 2.5.0/OpenVPN reconnect failing: This does need some further testing, and as far as I understand you can't push this setting. Correct, it can't be pushed since it's too late for it to have any effect -- the client is already sending traffic from its chosen port when it comes time to receive pushed settings. Clients would need to be redeployed with a new config or edited in-place. Since it appears to be a bug in OpenVPN it's something they'll need to address, but I'm not sure if anyone has reported it upstream yet.

The link is internal, not broken, but you don't need it. I linked to comment #11 on that issue which has an attachment that is the patch you need to apply.

@piotres One option, add the following to the client's config: auth-user-pass pass.txt then add a 2 line text file called "pass.txt" in the same folder as the client's config using the following format: username password Another option, create a separate instance for auto-connect users that auth's from certificate only. Another option, create a service account for auto-connect users, so solutions similar to the above can be deployed without input from the end-user. We did this at my last gig with Cisco AnyConnect. Another possible option, it looks like the "auth-user-pass" directive can be invoked via the command line, so it may be possible to add something like the following to the parameters section of the service instead of modifying the client config: --config C:\Program Files\OpenVPN\config\myvpnconfig.ovpn --auth-user-pass "C:\Program Files\OpenVPN\config\pass.txt"

@stan Glad that it's working now. Yeah, the outbound NAT often requires rebooting the box to apply the rules. Didn't think of it as well.

Use the following syntax to check the rules: # pfctl -a openvpn/{OPENVPNSERVERINTERFACE}_{USERNAME}_{REMOTEPORT} -sr For example: test1 - username 43256 - remote port from the Status / OpenVPN page: [image: 1614411017928-screenshot-from-2021-02-27-09-49-33.png] ovpns1 - interface name from the Status / Interfaces page (or from the ifconfig output): [image: 1614411035291-screenshot-from-2021-02-27-09-51-21.png] Let's try: # pfctl -a openvpn/ovpns1_test1_43256 -sr pass in quick on ovpns1 inet proto udp from 3.3.3.3 to 7.7.7.7 port < 566 no state pass in quick on ovpns1 inet proto udp from 3.3.3.3 to 7.7.7.7 port != 899 no state

@noplan I tried that first resulting in "You are only allowed to edit posts for 3600 second(s) after posting". An admin is welcome to update the title to reflect this.

The upgrade wouldn't have changed the gateway, but it's possible the gateway selected by the existing "Automatic" process changed to one that wasn't your preferred WAN. Setting a specific default (single gateway or failover group) is more reliable, so your suggestion is still a good change to make.

@bcruze Haven't restarted. What do the openvpn logs say?

@spinx I guess you need to reconfigure the client for no compression.

Sounds like you are using the wrong kind of setup. The addresses you list are from a net30 topology style server setup with one server and many clients. If this is the only client, you don't need a setup like that, just a plain peer to peer setup without the extra server parts.

@jairoav25 Yes in the past I tried to get DNS from them. Their advice was also to use Google or Cloudflare because officially they don't support pfSense. In since have moved away from ExpressVPN. There are beter options out there. Thank you for trying and sharing your experience!

@me-yro So you want to use a VPN service to access the internet. For now I cannot see that there is any of these subnets is defined on your pfSense interfaces. @me-yro said in openvpn connection initailised but no connection go throw it.: however, when i made the correct configuration for the subnets nothing work ( no internet connection ) Since you don't show it there is no way to verify. Is your VPN up? In the VPN settings check "Don't pull routes". So you can configure your new subnet and let them go out to WAN first. If all is working add the outbound NAT proper rules to the VPN interfaces and add policy routing rules to direct the traffic out. If there are issues post more details of your settings.

Happened again this morning, exactly between 7:29 am and 7:30 am. I checked the OpenVPN logs. There is absolutely no activity between 7:31:10 and 7:36:40, which is unusual. Typically someone is reconnecting every few minutes. Then, at 7:36:40, all 13 connected users have an inactivity timeout at the exact same time. After that, all remote users start aggressively connecting, every few seconds. By this point, the CPU is already at 100%. Starting at 8:16:59, the log starts throwing errors that no more IP addresses are available.