Finally, I found it. The server1.tls-auth file needed crlf on each line. When I copied that file it produced a single string of characters that was not formatted properly. After adding a crlf on each line and re-saving the openVPN server, returning to services found the openVPN server running.

I have to agree - posting in your native language might be easier.

I think your wanting to assign a specific IP to a openpvn client connecting to your pfsense... If so this would be a client override setup.

You would put in the client common name... Then in advanced do

ovrride.jpg

ifconfig-push 10.0.8.100 255.255.255.0

With the IP you want to give that client - for example, that is my work laptop, it always gets 10.0.8.100 as its IP..

That issue was solved.
So is yours !

I see a couple of things, which may not be the main issue, but could certainly be contributing to it:

Both sides are double NAT'd. Not ideal, but also not a big deal in and of itself as long as there's awareness of it and you have access to the edge device if an issue presents itself The server-side LAN is 192.168.74.0/24, but the client is routing 192.168.0.0/16 over the tunnel. This overlaps the server-side WAN subnet and is undoubtingly causing an issue of some kind since the server's WAN IP is 192.168.74.74. At a minimum, the client-side will need to modify the IPv4 Remote network(s) line to the correct server-side LAN subnet. Worst case, the server-side may need to assign a new LAN subnet if there's overlap somewhere and then adjust the config accordingly. The client-side WAN IP is 10.74.1.74, but the server-side is routing 10.74.1.0/24 over the tunnel which is the client-side WAN subnet. Why are we routing the client-side's WAN subnet over the tunnel here? This should probably be removed.

Other things to look at:

Verify the IIS server is using PFsense as the default gateway Verify the client-side's DNS is resolving the hostname to the correct IP

@jonathan-young said in pfSense not monitoring right ip with multi client openVPN connections:

Why does openVPN not measure the response from the server rather than my client?

Huh? OpenVPN does not measure anything and only monitors the server it is connected against (with its public IP) so it knows if the tunnel peer is down/unavailable.

It's simply a problem with overlapping IP ranges. You use multiple VPN connections with the same transit network. That is always resulting in routing mixups. It's simple routing 101, you can't correctly route the same network twice.

Thank you for the detailed response. So, I actually realized the VPN connection was down, and after removing the "-route-nopull" , it was connected again. There must have been a delay when I initially tested. Honestly I did a terrible job keeping track of everything I did. My firewall rules still look the same, although per your recommendations I can clean them up a bit. I believe the issue is that I did not have local DNS servers set in DHCP and there was no rule to allow connection to them, although I'm still not sure. I removed them, and left at default, and I believe that is when it started connecting.

Thanks @ilbicio
I want to create user by external (and automated) process (eg: an "Admin Panel") for my customer.

Your right, I recall that now, that's what I get for troubleshooting at 5AM.

@viragomann I don't know what was causing it, but I noticed that each time I would associate an interface with vpn server. It would cause that problem where vpn connects but no Internet, so all I had to is restart the OpenVPN server and create a rule under the interface, once the interface was created, and it been working for couple days.

Annotation 2019-12-10 093446.png Annotation 2019-12-10 093415.png

Add a domain override for network A to your DNS server in network B, so that DNS requests for hosts within that domain are forwarded to the DNS server in A. Allow DNS access from site B.
Then you should be able to resolve the hosts in A by <host-name.domain>.

OMG I'm sorry but maybe it'll help someone else in the future.
The problem was that the configuration of the VPN Service was set to

UDP4 IPv4 and IPv6 an all interfaces (multihome)

instead of

UDP on IPv4 only

Eversince I changed to that setting the tunnel works fine and in the config there was added
local 1.2.3.4
which is my CARP IP 😋

Might be a bit late and you probably already fixed it but try and take a peek at firewall -> rules -> openvpn.
You do have a rule to actually allow openvpn traffic through the firewall right?

Been discussed in this thread.. https://forum.netgate.com/topic/148713/cve-2019-14899

@JKnott
To be really honest...
A cosmic thing. Apparently not all VPN servers I've added (as client) are handing out ULA's. So on my dashboard it just looked sh*t.
Plus my OCD was hyping over this. ;-)

I just want one standard. So all three should give me an ULA or not.
Not just one.

Post new screenshots of both the client's routing table when connected and PFsense.

@stephenw10 said in Getting openvpn warnings in the logs:

You probably have Enable Negotiable Cryptographic Parameters set

Actually not. I disabled it since it seemed to not respect my preference and just use CBC if I remember correctly so I said F it lol
I'll live with those warnings.

Thank you :)

@JKnott said in Windows client version:

but pfSense creates a client for 2.4.8

Which is the current stable version from OpenVPN ;) OpenVPN connect client you refer is a) a beta and b) the client for the commercial RAS Server from OpenVPN Inc. as @Pippin already pointed out.

Never tried it though.

Post a network map. Post both the server1.conf and the client1.conf (both located in /var/etc/openvpn)

In order for your roadwarrior clients to access resources @ site B, two things need to happen:

Site A's road warrior clients need to know that site B's LAN subnet should be routed down the tunnel Site B needs to know where to send the return traffic for site A's road warrior clients

Based on the above, the following adjustments should be made to the configs:

Site A:

Road Warrior config should have "192.168.20.0/24, 192.168.10.0/24" on the IPv4 Local network(s) line. (Remove 10.0.20.0/24).

Site B:

Re-verify the site-to-site config has "192.168.20.0/24, 10.0.20.0/24" on the IPv4 Remote network(s) line

Once the site-to-site tunnel is re-established and the clients re-connect, you should be good to go.