Openvpn Remote host/IP in server config

Hello All,

I have setup an Openvpn between two Ipfire hosts, the server has static public IP, the client dynamic.

When the client changes IP, the VPN is broken.

I thought that “Remote host/IP” in the server configuration was not essential, given that is not flagged *, but it seems that if the value is not correct, tha VPN will not be established.

Is it correct, or am I missing something?

Thanks for your comments,
-Gian

Hello @gian .

The easiest thing is to set up a DDns to fix that problem.

wiki.ipfire.org - Dynamic DNS

Bye.

1 Like

I used nsupdate, and it was very unreliable.

I thought that if the VPN is initiated by the client, the only requirement would be to know where the server is.

Hello again.

I can help you little, since for a point-to-point connection, I use IPSec with a pre-shared key. With IPSec there is no such problem.

Maybe someone with more experience in OpenVPN connections can help you.

Greetings.

thanks just the same Roberto,
I appreciate your help.

@gian If I understand this, a client 192.168.1.10 connects to vpn server a.a.a.a Connection successful.
Later, the client changes ip to 192.168.1.20, tries to connect to vpn server a.a.a.a but fails?

Below is a sample configuration

On IPFire OpenVPN server


The Remote host/IP field on the server can be empty.

On IPFire OpenVPN client

Edit:
The above example was tested between:

IPFire OpenVPN server having a dynamic IP address from a public pool of cable TV provider + Dynamic DNS.

IPFire OpenVPN client having a dynamic IP address from a private pool of LTE provider (10.0.0.0/255.0.0.0).

1 Like

yes, this is what happens…

My server has a static IP, so the client will have that value in “Remote Host”.

However, if I leave that information blank on the server, the client will not connect.

Is this a private or public IP address?

What IP address does the client have - public or private?

I am talking about public IPs both sides

This scenario sounds like, I go to a coffee shop, get a public ip, vpn to the office, works. Then, I go to another coffee shop, get another public ip, vpn to the office, does not work. It could happen if the second coffee shop blocks vpn traffic.

Does the IPFire server respond to pings from the IPFire client?
Does the IPFire client respond to pings from the IPFire server?

Have you tried changing the UDP protocol to TCP on the client and server?

edit
In the boxe marked below, is the public IP address of the IPFire OpenVPN server written?

edit
The following IPFire Wiki page may be helpful

Hi tphz,
both screenshots lines completely different instances of IPFire out. The first one is the Roadwarrior instance (net30 topology) the second is Net-to-Net (P2MP topology). Both instances can not work with another cause of the instance differences.
In here → wiki.ipfire.org - OpenVPN Configuration you can find explanations for both configuration possiblities. Or on Youtube for RW → IPFire Openvpn roadwarrior - YouTube and N2N → IPFire OpenVPN Net-to-Net - YouTube sadly in german but may the screen can give you also some ideas what you can do.

Best,

Erik

FYI: for the YT videos, I enabled captions, Auto-Translate, English and the translation is good.

2 Likes

Hi Erik, you’re absolutely right :smiley:

However, what I meant was that the address of the IPFire OpenVPN server, is taken into the client file, from the “Local VPN Hostname/IP” field

image

…and then imported to the IPFire OpenVPN client.


And not everyone may be aware of it.

P.S.
I changed my previous post, is this okay?

Regards
Tom

It is a site2site setup, both sides Ipfire.

The server will reply to ping from the client, given that the server address is known, whereas the server can’t ping the client if the service provider has changed IP, because this one will be unknown.

Site2Site use the dynamic dns on it the remote machine that is. Use a dynamic dns service on that ipfire box under services they have multiple to choose from. Then use that name in the field for the vpn setup instead of ip. PS not sure it was fixed in the last two releases as the client side was broken and I had to use 157 release to get the certs to import correctly.