Is this a natural outbound request for OpenVPN connection?

Gertjan

You mention two different VPN enteties :
An OpenVPN server, hosted by pfSense ( ? )
Is it correct that you a NAT rule on Sonic "any source" to the pfSense IP, port 2018 UDP ?
A VPN provider - which means you use a VPN client on pfSense, or on any LAN device, to connect to this provider. Correct ?

Btw : why place a "sonic wall" in front of pfSense ?

johnpoz

@gertjan said in Is this a natural outbound request for OpenVPN connection?:

Btw : why place a "sonic wall" in front of pfSense ?

Prob doesn't want to pay for the vpn license - but yeah I would just replace the sonic wall with pfsense. Think you might even be able to run pfsense on some sonicwall appliances?

But to the port, the source port of a client coming in could be really anything above 1023, so sure a firewall in front of your vpn server could see traffic to some random port

IP is my VPN provider

This makes it sound like pfsense is not really vpn server, but being used as client to some vpn provider - if that was the case, then yeah that destination port would be the port your vpn server your connecting from on pfsense. Are you saying this 2018 port is not the port your vpn provider uses?

Running a vpn server or client (that other local devices leverage for vpn) can be problematic with asymmetrical traffic flow, unless setup on a transit network.. It always simpler setup to run the vpn at the edge device.

Gertjan

@johnpoz said in Is this a natural outbound request for OpenVPN connection?:

Prob doesn't want to pay for the vpn license

OpenvPN server and client are open source, and Sonic has made it pay-ware ?
( just to satisfy my own curiosity )

johnpoz

@gertjan not sure if they use openvpn, but the ssl vpn option they have is lic

https://www.sonicwall.com/support/knowledge-base/how-do-i-buy-ssl-vpn-licenses-on-mysonicwall-com/200319114156353/

musicims

@gertjan said in Is this a natural outbound request for OpenVPN connection?:

@musicims

You mention two different VPN enteties :
An OpenVPN server, hosted by pfSense ( ? )
Is it correct that you a NAT rule on Sonic "any source" to the pfSense IP, port 2018 UDP ?
A VPN provider - which means you use a VPN client on pfSense, or on any LAN device, to connect to this provider. Correct ?

Btw : why place a "sonic wall" in front of pfSense ?

Correct VPNserver with PF behind the sonicwall with that NAT in place. Sonicwall does all the packet filtering on specific clients once its decrypted by PF

@johnpoz said in Is this a natural outbound request for OpenVPN connection?:

@gertjan said in Is this a natural outbound request for OpenVPN connection?:

Btw : why place a "sonic wall" in front of pfSense ?

Prob doesn't want to pay for the vpn license - but yeah I would just replace the sonic wall with pfsense. Think you might even be able to run pfsense on some sonicwall appliances?

But to the port, the source port of a client coming in could be really anything above 1023, so sure a firewall in front of your vpn server could see traffic to some random port

IP is my VPN provider

This makes it sound like pfsense is not really vpn server, but being used as client to some vpn provider - if that was the case, then yeah that destination port would be the port your vpn server your connecting from on pfsense. Are you saying this 2018 port is not the port your vpn provider uses?

Running a vpn server or client (that other local devices leverage for vpn) can be problematic with asymmetrical traffic flow, unless setup on a transit network.. It always simpler setup to run the vpn at the edge device.

It is a client to a VPN provider for encrypted traffic to specific clients. I realize it is much simpler but needed because sonicwall VPN SSL sucks. Could you elaborate on the asymmetrical traffic flow issue? Not familiar with that

I should also be more specific here. I am getting this connection with sonicwall WAN DOWN for testing to make sure everything is secure both connected and not connected. The only thing that should be going on here is PF attempting to make a openvpn connection to that VPN IP and nothing else. Dont know why I'm seeing that port coming out of it when it is specifically 2018 from PF. Its obviously getting translated in the sonicwall, but I assumed the default WAN of PF would only need 53 to begin to establish the connection then 2018 for the handshake portion once the tunnel was established. I was only expecting to see these two port #s trying to reach out of PF

johnpoz

@musicims only seeing connection from the .249 to 2018, did you post the wrong picture?

musicims

@johnpoz The .249 is PFs address yes with outbound to the VPN 2018. Just not sure why PFs making this request through port 55273

johnpoz

@musicims said in Is this a natural outbound request for OpenVPN connection?:

through port 55273

That is the source port..

musicims

@johnpoz So its normal for PF to use any port to make the outbound request even though the VPN tunnel is 2018?

I was wanting to make it on that subnet that PF is on to strictly only allow the ports needed to establish the VPN

Rico

-Rico

johnpoz

@musicims said in Is this a natural outbound request for OpenVPN connection?:

quest even though the VPN tunnel is 2018?

Its normal for anything to use some what looks like a random source port above 1023.. What is RARE, I mean RARE is that the source port would be the same as destination port.. I think ntp might do this some times where its 123 to 123, zone transfers in dns use to or could be 53 to 53.. etc..

Look at all your other connections there from .163 to 443, those are all what appear as "random" high ports..

This is how tcp and even udp works, where the source port is going to a port out of the range the OS is set to use, they are by rfc I believe 1024-65535

Here is from windows for example

$ netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 1024
Number of Ports : 64511

Different OSes could you slightly different ranges. These are normally called ephemeral ports.

Keep in mind if your natting in pfsense, since it uses napt (network address port translation) when say a client wants to talk to some http the traffic would be clientIP:X --> DestIP:80

Now when pfsense changes that to its wan IP it would look like wanIP:Y --> DestIP:80

Pfsense doing napt would change the source port of the traffic..

But yeah source port is always going to be something pretty much random - Don't take this the wrong way but how is it your running firewalls and do not understand what a source port is?

musicims

@johnpoz said in Is this a natural outbound request for OpenVPN connection?:

@musicims said in Is this a natural outbound request for OpenVPN connection?:
Don't take this the wrong way but how is it your running firewalls and do not understand what a source port is?

Still learning. I appreciate your help! I know about ephemeral ports and RFC 6335 but did not know that it also applied to vpn tunnels, I guess I was under the assumption that it was only for "normal" traffic.

@rico said in Is this a natural outbound request for OpenVPN connection?:

-Rico

Doh, this is perfect. Thank you so much. I've looked through that so many times I guess I was blind to it.

Anyway thank you all for your help! Much appreciated

Pippin

Just to add info about ports:
https://youtu.be/g2fT-g9PX9o?t=300