@viragomann Yes the same local database for all users. I guess this can be chalked up to "gremlins" in the system. All the other accounts using the openvpn are still working after the host name resolution change. I even considered the fat finger syndrome - :) - but that was eliminated with repeated copy/pastes. Still scratching my head on the cause? However, it in now not as critical, since I have a work around. I appreciate your help!!

@viragomann
Hmm, not sure I already did that. But let's see. Thanks.

@utnuc said in Client can't see LAN servers after connect:

creating an A-Record with cloudflare to point to 10.0.0.2,

Well that tells me your client isn't using your local dns then, but you said it resolved to 10.0.0.2 - so maybe your browser wasn't using your dns.. But using doh, the makers of the browsers being smarter than us love to point the browser to their dns vs you know the one we tell the OS to use ;)

When you defined the OVPN, you specified an IP range to assign the incoming connection. By default, traffic OUT of those ranges is allowed and the traffic IN to the subnets/VLAN is BLOCKED. Simply go to each of the subnets and ALLOW traffic from the OVPN ranges appropriately.

@omegahacker
As I mentioned, it is due to the reply-to tagging is not happening if a pass rule on an interface group matches the incoming traffic.
OpenVPN is an interface group. It is generated automatically, when firing up an OpenVPN instance, be it a client or a server.

The reply-to is needed to route response packets back to the proper non-default gateway.
The reply-to tagging is done by the firewall rule, which passes the traffic.

However this requires that the interface is unique. Since rules on interface groups or floating rule can be applied to multiple interface, it isn't unique and the reply-to tagging is not done by such rules.

And yes, interface group and floating rules have priority over interface rules. Hence you have to care, that there is no pass rule matching the incoming traffic on a non-default gateway interface for proper routing back the respond packets.

Here is my transfer performance using Wireguard

DOWNLOADING FROM SERVER (Server upload performance)
fa6458705745c2fe12cf2ee4b989de6b[1].png

UPLOADING TO SERVER (Server download performance)
cbd266b143cfdf96762c54a44e8b5656[1].png
I'm very happy with these results.

@nettolc91

What was the IP you were using , 192.168.1.1 ?
Should work if you use the 'perfect' VPN (server) 'LAN' rules :

aab00203-dcb3-4870-bad7-b135e433809b-image.png

My OpenVPN server uses the "192.168.3.1/24" tunnel, my phone got 192.168.3.3, and I could access 192.168.1.1 (the LAN pfSEnse IP) just fine.

edit : oh lol : The GUI web server also listens on 192.168.3.1 (The VPN interface) so I could access the pfSense also using that IPv4.

@Bambos said in site-to-site OpenVPN with client side with dynamic IP and behind NAT:

Maybe you have setup (in the beginning a firewall rule taking into consideration the "source IP" as well ??

Yup, I'm a dummy. That was it. My firewall rule for the OpenVPN port (standard is 1194) was restricted to an Alias Group containing all the public IPs of my clients. I've disabled that group for now - just until I can get a static IP for the client that moved.

Thanks!

@dgall

On the Client Export tab, select Inline Configuration. I use Network Manager on openSUSE and it can directly use the OVPN file.

@LukasH
With Inter-client communication enabled, pfSense cannot filter the traffic, because it doesn't enter the interface.

@viragomann I've switched FastestVPN to use their wireguard option as all of my wireguard connections are working.. only OpenVPN having issues... so at this moment, the only VPNSecure isn't working as wireguard isn't available on that provider. But the original FastestVPN openvpn connection had the same exact problem.. nothing goes out.. but can access LAN

Hi @Aseknet
I apologize for the delay in responding. I made the recommended changes and tested them on the same day, but there was no difference.

However, yesterday I tried reconnecting and it started working. The new exported client from AES-256-GCM and the old are also functioning properly. I can't figure out if the issue was with the key or my ISP. Thank you so much.

@brepo

I feel a little sorry for myself, because I spent more than 10 years with pfsense and everything suited me before :)

Another advantage is the ability to use the cryptographic acceleration hardware built in the firewall Netgate appliances, the use of DOC, control access with radius, or even set up local access policies, direct use of syslogs and a granular level of security by way of a magnitude of logs available directly on the firewall, a separate access control list can be used for OpenVPN. Share a NAS private cloud with your family for photos and large files. Many types of encryption algorithms are also available, and Netgate’s open source community that can help you with issues. Finally scheduling, an ability to set up when users can access the VPN even lock it completely out on holidays.

@PerfectBake420 NVM. I had a failover internet on the same IP scheme as Site 1.

I've crawled through the routing tables (previously posted), and I find nothing incorrect. The tracert result from a client behind the Z router/OpenVPN client to a client behind the Y router/OpenVPN server shows the correct first two hops, and I can see no reason why it should not find the final destination (10.55.73.193):

@wmcneil said in SG1100: routes seem correct, but not working:

tracert from Z windows client (192.168.2.135) to Y client 10.55.73.193:

> > 1 1 ms <1 ms <1 ms cabin_pfSense.localdomain [192.168.2.1] > 2 33 ms 31 ms 39 ms 10.55.203.1 > 3 * * * Request timed out.

Been overseas for a few weeks sorry.
So yeah, i have tried different servers, even TCP.
But they all DC under load.

What i have also now done, is setup a VPN gateway group, with two VPNs in it for failover.
What i have been noticing is that sometimes when one fails, the other takes over in under 10ish secs, so all good. But sometimes when one goes, the other fails at the same time, so yeah ded.

I have been in contact with PIA, my VPN supplier, and they are bloody useless. He started going on about how their VPN app running on the end clients is the best way as its the most configurable...
I kind of gave up on PIA support after that haha.

I have posted my config to one of my VPNs for anyone to have a look to see if they can see any glaring issues?
BTW, when i took that, i had the custom options feild empty. I have now got:
resolv-retry infinite
persist-key
persist-tun
tls-client
remote-cert-tls server
compress
reneg-sec 0
In there and it seems to like those settings i think? (some might be redundant)

I have it running on an old PC with dual NICs (and with AES-NI) And untill not all that long ago, it was fine.
What im thinking now, is that i should buy one of those little gateway devices like the Protectli Vault FW4B or something as it might be a hardware error? Whats you peoples thoughts

signal-2024-01-11-100631.jpeg

Has anyone using OpenVPN on Yealink phones experience this issue after upgrading? These phones report to a FreePBX system, maybe this is a blessing in disguise and another good reason to move to a different phone system!