Address in use error binding to wrong port

[zootallures]

I have a ClearOS (based on RHEL) gateway box which runs an OVPN server bound to tcp port 1194 on all interfaces. No problem here.

[oconf=] <== Doesn't appear to work

Code: Select all

port 1194
proto tcp-server
dev tun
# etc...

On the same server I am setting up an OVPN client to tunnel through a messy multiple-NAT connection to a public VPN gateway (safervpn.com) using tcp port 443. Apart from some routing problems it's working fine but I need this client to connect through a specific interface so I added a --local option for the interface and got this error:

TCP/UDP: Socket bind failed on local address [AF_INET]192.168.3.5:1194: Address already in use

Config is:

Code: Select all

client
dev tun1
proto tcp
remote nz1.safervpn.net 443
local 192.168.3.5
# etc...

So what's going on here? Why would OpenVPN try to bind to 1194?
It's either lost the plot or there's something I'm missing. Can anyone shed some light on this please.

Linux version 3.10.0-327.36.1.v7.x86_64 (mockbuild@build64-1.clearsdn.local) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Tue Sep 20 12:29:12 MD

OpenVPN 2.3.12 x86_64-redhat-linux-gnu

[TinCanTech]

--local implies --bind, --bind requires to bind to an address and port. Default port is 1194 ..

You can either specify a local port --lport or not use --local ..

[zootallures]

*Slaps forehead* I need to stop working so late at night.

Of course, --lport fixes the problem. Thanks TimCanTech.

[Skaperen]

what's wrong with using 1194? i've heard it's a popular choice. or is this a 2nd OpenVPN tunnel?

[zootallures]

Yes, 1194 is the default and commonly used port, but I have a separate OpenVPN connection using it.

I mistakenly thought it would bind to the local 443 when I specified --remote port 443, but no, it binds to 1194 unless changed with a --lport.

[Skaperen]

gotcha, so the fact that something else is bound to port 1194 is legit. so there was a real need to change the local port. my thing that auto-configures a tunnel between AWS regions has to do this to avoid a like issue because it might be configuring for 3 or more regions (2 or more tunnel endpoints at this instance). the solution i did is to pick a random port (still a tiny chance of collision). someday, i will add some code to detect a collision and pick another.