OpenVPN client connecting from unusual port number

[adamw]

Hi all,

pfSense: 2.4.4-p3
OpenVPN: 2.4.8
IPv4 only

All clients are configured to connect to the standard 1194 UDP service and for all of them /status_openvpn.php is showing their public IP followed by :1194

Apart from one!

This one is showing Public_IP: 33546

Same port is showing in OpenVPN routing table and /diag_dump_states.php

This client a standard 2.4.8 installer (exported from pfSense) and running on Win 10 Pro.

No difference launching as Administrator vs standard user.

There seem to be no issues with traffic inside that OpenVPN tunnel.

Can somebody explain it? Is it a bug?

Thanks,
Adam

[adamw]

I think the reason is another VPN service (privatevpn.com) being installed on the same client.
The software must have figured out a potential conflict and addressed it by assigning a different random high port number.

[Gertjan]

Noop.

I VPN into my work :

you saw the port ? 62653 !

I disconnect, and reconnect.
Guess what : another port number !! => 52100 !

The destination port of a web server is 80 - 443 if it's https. You know that.
You should know that the web browser being used to visit a web site are using any possible port between 1024 and 65534.

Only rather special severs like mail servers connecting to mail servers use port "25" (source) to port 25 (destination).

Source ports are normally always random.

[JKnott]

@adamw

That's entirely normal. With both TCP and UDP, the source port is supposed to be random. This is to allow multiple connections between 2 devices. If they all used the same source port, it wouldn't be possible to tell them apart.

[adamw]

That's what I thought re high port numbers.
BUT...
Why ALL the other clients I can see (i.e. several) report PUBLIC_IP:1194 in real address just not mine?
I know they connect from Linux and various versions of Windows and use different client versions.

[Gertjan]

Normally, the client software chooses a random outgoing port.
But isn't not forbidding to override this behaviour, and choose a port.

And now the urban legends phenomenon kicks in : people see the word "VPN", so they think they have to choose "1194" (even) when they use a VPN client.
Which is based on upon ... nothing.

It would still work, because, when ports are the same, the incoming IP's are not.
If both the IP and port are the same for two incoming connection then you have that typical situation that starts with
"Bug in pfSense ......"

[Rico]

For my OpenVPN Clients (I have a LOT) I very often see high ports on CGN connections but default OpenVPN port 1194 for clients using a real public IP. Guess why.

-Rico

[adamw]

@Rico
I'm guessing I should consider myself lucky then? :)
Is there an easy way to determine if ISP utilises CGN or not?

[JKnott]

@Gertjan said in OpenVPN client connecting from unusual port number:

But isn't not forbidding to override this behaviour, and choose a port.

For example, DHCP, the server is 67 and client is always 68. There are some other protocols with similar but, generally, the source port is random.

[JKnott]

@adamw said in OpenVPN client connecting from unusual port number:

Is there an easy way to determine if ISP utilises CGN or not?

Yes, check the IP address you get. There's a block just for CGN, 100.64.0.0/10.

[adamw]

Hmm, neither of my clients' public IPs is on 100.64.0.0/10 range.

[JKnott]

@adamw

Perhaps RFC 1918 then?

Can you ping their WAN address from elsewhere? If you can, then they have a public address.

[Pippin]

Or a test site?
https://ip.bieringer.de/cgn-test.html

Or trace?
traceroute -n -U 8.8.8.8
traceroute -n -UL 8.8.8.8
traceroute -n -T 8.8.8.8
traceroute -n -I 8.8.8.8

[Rico]

The easy way is check your Routers WAN IP and compare with a site like whatismyipaddress.com
If the IP is different you are using CGN.
With the Router WAN IP RFC1918 you don't need to check any further of course, then it is 1000% CGN.

-Rico