Discussion:
[Openvpn-users] lport vs no lport
s***@keemail.me
2017-04-10 08:34:59 UTC
Permalink
Hello!
I have a project, where I connect/disconnect numerous times with a single client to my OpenVPN server within a short time (e.g. 70 connect/disconnects within 10 minutes).

Now, if I configure a specific lport in the client configuration (anything between 32768 and 60999), I get a lot of errors that the port is already in use.

"TCP/UDP: Socket bind failed on local address [undef]: Address already in use"

I guess this is because, the port hasn't been made available yet, after the last OpenVPN process terminated. I terminate the OpenVPN process gracefully and use `explicit-exit-notify 3` if that makes a difference.
However, I don't seem to have this issue when I don't use the `lport` at all, and let OpenVPN use the default.

I don't see much of a difference there. Is it the high port number that is used by `lport`?
Does this even relate the OpenVPN or is it more of an issue of the host operating system?

I can't use the default `lport`, as I want to be able to start multiple OpenVPN instances on the client.

Does anyone have an idea, how I could resolve or at least mitigate this issue?

Thanks and kind regards,
SaAtomic
Илья Шипицин
2017-04-10 09:10:46 UTC
Permalink
Post by s***@keemail.me
Hello!
I have a project, where I connect/disconnect numerous times with a single
client to my OpenVPN server within a short time (e.g. 70
connect/disconnects within 10 minutes).
Now, if I configure a specific lport in the client configuration (anything
between 32768 and 60999), I get a lot of errors that the port is already in
use.
as for https://tools.ietf.org/html/rfc6056#page-5
ports "49152 through 65535" are recommended for outgoing ports (unless
specified manually)


it means, any application can take random port from that range for outgoing
connection (it happens due to OS choice)

be careful with Ephemeral ports
Post by s***@keemail.me
"TCP/UDP: Socket bind failed on local address [undef]: Address already in use"
I guess this is because, the port hasn't been made available yet, after
the last OpenVPN process terminated. I terminate the OpenVPN process
gracefully and use `explicit-exit-notify 3` if that makes a difference.
However, I don't seem to have this issue when I don't use the `lport` at
all, and let OpenVPN use the default.
I don't see much of a difference there. Is it the high port number that is used by `lport`?
Does this even relate the OpenVPN or is it more of an issue of the host operating system?
I can't use the default `lport`, as I want to be able to start multiple
OpenVPN instances on the client.
Does anyone have an idea, how I could resolve or at least mitigate this issue?
Thanks and kind regards,
SaAtomic
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users
s***@keemail.me
2017-04-10 09:13:17 UTC
Permalink
hello!
You're right. I use the ephermal ports that are given by the local system (/proc/sys/net/ipv4/ip_local_port_range) and I verify if the chosen port is actually available before starting OpenVPN with it, so that should not be the problem.

Kind regards,
SaAtomic
Post by s***@keemail.me
Post by s***@keemail.me
Hello!
I have a project, where I connect/disconnect numerous times with a single client to my OpenVPN server within a short time (e.g. 70 connect/disconnects within 10 minutes).
Now, if I configure a specific lport in the client configuration (anything between 32768 and 60999), I get a lot of errors that the port is already in use.
as for > https://tools.ietf.org/html/rfc6056#page-5
ports "49152 through 65535" are recommended for outgoing ports (unless specified manually)
it means, any application can take random port from that range for outgoing connection (it happens due to OS choice)
be careful with Ephemeral ports
 
Post by s***@keemail.me
"TCP/UDP: Socket bind failed on local address [undef]: Address already in use"
I guess this is because, the port hasn't been made available yet, after the last OpenVPN process terminated. I terminate the OpenVPN process gracefully and use `explicit-exit-notify 3` if that makes a difference.
However, I don't seem to have this issue when I don't use the `lport` at all, and let OpenVPN use the default.
I don't see much of a difference there. Is it the high port number that is used by `lport`?
Does this even relate the OpenVPN or is it more of an issue of the host operating system?
I can't use the default `lport`, as I want to be able to start multiple OpenVPN instances on the client.
Does anyone have an idea, how I could resolve or at least mitigate this issue?
Thanks and kind regards,
SaAtomic
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! >> http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Selva Nair
2017-04-11 02:38:06 UTC
Permalink
Post by s***@keemail.me
I have a project, where I connect/disconnect numerous times with a single
client to my OpenVPN server within a short time (e.g. 70
connect/disconnects within 10 minutes).
Now, if I configure a specific lport in the client configuration (anything
between 32768 and 60999), I get a lot of errors that the port is already in
use.
"TCP/UDP: Socket bind failed on local address [undef]: Address already in use"
Use of exit-notify indicates you are using UDP. In that case as soon as the
process is terminated the port will become available. If the port is still
in use either the previous process has not yet exited or some other process
might have grabbed it in the mean time. There is no reliable way to avoid
the latter -- if you need a custom port do not pick it from the ephemeral
range.
Post by s***@keemail.me
I guess this is because, the port hasn't been made available yet, after
the last OpenVPN process terminated. I terminate the OpenVPN process
gracefully and use `explicit-exit-notify 3` if that makes a difference.
Note that sending exit notify 3 times will take about 3 seconds. You can
leave out the number (or set it to 1) to notify just once and speed up the
exit to about a second or so. Unless your network so unreliable that 3
tries are needed.
Post by s***@keemail.me
However, I don't seem to have this issue when I don't use the `lport` at
all, and let OpenVPN use the default.
I don't see much of a difference there. Is it the high port number that is used by `lport`?
Does this even relate the OpenVPN or is it more of an issue of the host operating system?
I can't use the default `lport`, as I want to be able to start multiple
OpenVPN instances on the client.
Does anyone have an idea, how I could resolve or at least mitigate this issue?
Why not use --nobind and leave out --lport?

Selva
s***@keemail.me
2017-04-11 05:25:25 UTC
Permalink
Hello!
Post by s***@keemail.me
I have a project, where I connect/disconnect numerous times with a single client to my OpenVPN server within a short time (e.g. 70 connect/disconnects within 10 minutes).
Now, if I configure a specific lport in the client configuration (anything between 32768 and 60999), I get a lot of errors that the port is already in use.
"TCP/UDP: Socket bind failed on local address [undef]: Address already in use"
Use of exit-notify indicates you are using UDP. In that case as soon as the process is terminated the port will become available. If the port is still in use either the previous process has not yet exited or some other process might have grabbed it in the mean time. There is no reliable way to avoid the latter -- if you need a custom port do not pick it from the ephemeral range.
Correct, I use UDP. The process is definitely stopped before a new OpenVPN client is started.  I'll have to investigate this further, very odd behaviour.


Why should I choose a port outside of the emphermal range? What does that change for me?
Post by s***@keemail.me
I guess this is because, the port hasn't been made available yet, after the last OpenVPN process terminated. I terminate the OpenVPN process gracefully and use `explicit-exit-notify 3` if that makes a difference.
Note that sending exit notify 3 times will take about 3 seconds. You can leave out the number (or set it to 1) to notify just once and speed up the exit to about a second or so. Unless your network so unreliable that 3 tries are needed.
Thank you for the hint!
 
Post by s***@keemail.me
However, I don't seem to have this issue when I don't use the `lport` at all, and let OpenVPN use the default. 
I don't see much of a difference there. Is it the high port number that is used by `lport`?
Does this even relate the OpenVPN or is it more of an issue of the host operating system?
I can't use the default `lport`, as I want to be able to start multiple OpenVPN instances on the client.
Does anyone have an idea, how I could resolve or at least mitigate this issue?
Why not use --nobind and leave out --lport?
Selva
I can not use --nobind, as I connect/disconnect/reconnect a large number of times, which completely exhausts my IP pool on the server within minutes. This topic was discussed earlier on the mailing list in case you missed it. Thank you for the suggestion though, would be a perfect solution, if I didn't have the issue with the IP pool exhaustion.




Kind regards,

SaAtomic
debbie10t
2017-04-11 11:02:05 UTC
Permalink
Post by s***@keemail.me
I can not use --nobind, as I connect/disconnect/reconnect a large
number of times, which completely exhausts my IP pool on the server
within minutes. This topic was discussed earlier on the mailing list
in case you missed it. Thank you for the suggestion though, would be
a perfect solution, if I didn't have the issue with the IP pool
exhaustion.
How does --nobind effect --ifconfig-pool ?

Perhaps, if you identify that you can solve your problem ..


Using

Server: --topology subnet --server {subnet} 255.255.0.0 --duplicate-cn
--keepalive 3 15
Client: --nobind --client

Should, theoretically, allow you to dis/re-connect 1000+ times per
minute, indefinitely.

Regards
Selva Nair
2017-04-11 16:15:34 UTC
Permalink
Post by s***@keemail.me
Does anyone have an idea, how I could resolve or at least mitigate this
Post by s***@keemail.me
issue?
Why not use --nobind and leave out --lport?
Selva
I can not use --nobind, as I connect/disconnect/reconnect a large number
of times, which completely exhausts my IP pool on the server within
minutes. This topic was discussed earlier on the mailing list in case you
missed it. Thank you for the suggestion though, would be a perfect
solution, if I didn't have the issue with the IP pool exhaustion.
This very likely indicates use of --duplicate-cn on the server and not
sending exit-notify from client on exit. Else it should be possible to
repeatedly connect without exhausting the ip pool. Post your server logs
showing how its handling repeated connections.

Selva
s***@keemail.me
2017-04-12 06:28:20 UTC
Permalink
Hello,

I do use --duplicate-cn on the server, but I'm not sure if the exit-notify is correctly registered by the server. Thank you for the suggestion - I'll send the logs as soon as possible.

Kind Regards,
SaAtomic
Post by s***@keemail.me
Post by Selva Nair
Post by s***@keemail.me
Does anyone have an idea, how I could resolve or at least mitigate this issue?
Why not use --nobind and leave out --lport?
Selva
I can not use --nobind, as I connect/disconnect/reconnect a large number of times, which completely exhausts my IP pool on the server within minutes. This topic was discussed earlier on the mailing list in case you missed it. Thank you for the suggestion though, would be a perfect solution, if I didn't have the issue with the IP pool exhaustion.
This very likely indicates use of --duplicate-cn on the server and not sending exit-notify from client on exit. Else it should be possible to repeatedly connect without exhausting the ip pool. Post your server logs showing how its handling repeated connections.
Selva
Loading...