That would be up to the RADIUS server. Capture and check requests from each OpenVPN instance and look for attributes that are unique there which it could use to distinguish between the two (e.g. Calling-Station-Id). Or setup two Authentication Server entries on pfSense pointing to the same server but with different RADIUS NAS IP Attribute settings. Then in your RADIUS config you should be able to tell it to only authorize a user if they match along with whatever other attribute you decide to use.

@MrGlasspoole said in Dynamic DNS not working - fixed IP works: What do you mean? My web hoster is a well known company in Germany. And you can select it in the pfSense DDNS settings. Hummm. What has the web host to do with this ? They - the web host - have a static IP - .... @MrGlasspoole said in Dynamic DNS not working - fixed IP works: And as i wrote. The IP updating to the DDNS server is working. .... And i get back the IP from my website. So, it's not working - it shouldn't not return the IP of this web host / web site - it should return the IP of your WAN at that moment. Example : I have a dedicated server on the Internet - and a hand full of domain names. One is "test-domaine.fr". Check out : root@ns311465:~# dig test-domaine.fr A +short 5.196.43.182 So, 5.196.43.182 is an IP4v of this dedicated server. "www" is the same : root@ns311465:~# dig www.test-domaine.fr A +short 5.196.43.182 But I have also an "URL" that points to my pfSense / WAN IP : root@ns311465:~# dig br*t.test-domaine.fr A +short 82.127.*4.254 and that's correct, that IP is my WAN IP right now. So, I can use "br*t.test-domaine.fr" as an URL that conenctes me to my .... OpenVPN running on my pfSense. When my WAN IP changes, pfSense will take care of updating the A record for br*t.test-domaine.fr using DYNDNS (actually, its RFC2136 based, using my own 'bind' master domain server, running on that server). Again : show us your logs ...

You will need to write something that loops through the /cf/conf/config.xml and extracts the certificates, runs them through a base64 decode, and saves the results in a format that makes sense to you.

@PrashantRai said in OpenVPN (Site-to-Site) unable to ping/access from SiteA(Server) to SiteB(Client) LAN from Local Machine: also how to know if IP's are overlapping!!!! You don't understand network masks, ie subnetting - but your setting up the firewall and site to site vpn? How is this? So you rust randomly picking a mask? Where did you come up with the /12? I can understand the /8 somewhat since this is whole network for 10.. I would highly suggest you do a bit of research. https://www.ittsystems.com/introduction-to-subnetting/ Came up on google like first hit, looks basic enough to get you started.

Hello thank you very much, that's exactly what i want best regards

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 [image: 1576333639009-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. [image: 1575988471469-annotation-2019-12-10-093446.png] [image: 1575988471407-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