@Gertjan said in OpenVPN client frequently change tunnel IP address:

Normally, the internal DHCP server build into the VPN server will give the same IP to the same device when it comes back.

If the client tries to reconnect within the default --keepalive 10 60 setting, then the server gives a different tunnel IP. This is because the server doesn't know the client has lost it's connection. It can take up to 120 seconds before the server realizes/assumes that the client is gone.
Even if the client is assigned a static tunnel IP based on it's certificate CommonName through Client Specific Overides. It is no guarantee the client gets the same IP. Even not with --ifconfig-pool-persist ips.txt

The following is the only way to assure the client gets the same IP:

server 10.0.8.0 255.255.255.0 'nopool' ifconfig-pool 10.0.8.101 10.0.8.253

In this example 10.0.8.2 till 10.0.8.100 can be used for static assignment, 10.0.8.101 till 10.0.8.253 for dynamic assignment.

https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

OK, he's fixed up. Let's call it a day.

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/authenticating-openvpn-users-with-radius-via-active-directory.html

Set up syslog and view the logs there.

@tronix said in Pid openvpn client:

client description

Those would be dependent on either using the ovpns/ovpnc interface - which wouldn't be any more specific than using the PID like now - or showing the description the user enters while configuring the client or server setup. So if nothing is entered as description, what should be shown? You see, it's not that hard showing something but hard to show the right thing ;)
Also having to dig out the ovpn interface and description belonging to the specific PID (the log that is shown is the system log from OpenVPN itself) would require multiple calls to parse config.xml or ovpn config files to read the informations so would probably slow down log parsing/showing, too.

@chorong761 This post is from 2017 and the last time this user was online was May 2018. Start a new thread.

key-direction 1;

Needed to be in custom options under advanced configuration; thanks @Pippin !!!

I had a case once where nothing worked until you changed the compression on both sides from No compression to Adaptive LZO. That makes no sense to me whatsoever, but it worked one way but not the other.

Is either bridge assigned itself as an interface?

Any other difference between them?

This is certainly odd....

Steve

@Rico said in pfsense - TLS error TLS handshake failed:

Second you need to disable Block private networks and loopback addresses (Interfaces > WAN)

Not needed, since the source would be public - unless the nat router in front of pfsense was doing source natting? Which normally not the case.

As you can see from actually looking at the rules

block drop in quick on igb1 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8" block drop in quick on igb1 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8" block drop in quick on igb1 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12" block drop in quick on igb1 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16"

They are only block when source matches rfc1918, not dest.. So forwarding the case of double nat to pfsense wan IP that is rfc1918 is not an issue with the default block private networks rule that is on wan. So no need to disable it - unless the source is going to be rfc1918.

Added to what @NogBadTheBad said :

Start up a new OpenVPN server on - example - port 1195.
Assign this user - his credentials - to this VPN.
Assign the OpenVPN interface of this instance to an Interface.
Now you can use this firewall for this interface to fine-grain the access on IP "destination".

When a user comes in using a VPN, he can access - typically - your LAN(s). But all devices on these LANs have their own access codes.
The server your user should access has it's own user privileges set up, right ?

Btw : put your server on a DMZ ....

Of course... thank you.
I was looking at the rules over and over and never thought of looking at the "Remote Network" in the VPN settings.

Can someone at least give me an idea of which exported profile I should be using.

Post a screenshot of your rules so we can see what you've done.

It might be best for you to leave them at their defaults unless you have a specific reason for changing them. Some say that compression isn't required at all. This was an interesting read that talks a lot about compression and its effects:

https://hamy.io/post/0003/optimizing-openvpn-throughput/

Yes, of course !

That's normal. Those routes are internal to OpenVPN (iroutes) which is explained in the text on the fields in the overrides.

If you want the subnets to be routed into OpenVPN in the routing table you need to enter them as IPv4/IPv6 Remote Network(s) entries on the server, not in overrides.

In Peer to Peer ( SSL/TLS ) mode i have tried add "keepalive 2 5" in Custom options on Server side (if type high values, it did not help in client reconnection, but on client reboot higher values works, it's important that keepalive was lower, than client reconnection time take), and seems that it helps shows correct link state on Server side.
Seems that client make "reconnection" very fast, that Server status did not catch new connect in default pfSense's "keepalive 10 120" or something look like this.