LinuxQuestions.org - Firewall (client router or client OS) blocking outgoing VPN?

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Firewall (client router or client OS) blocking outgoing VPN? (https://www.linuxquestions.org/questions/linux-networking-3/firewall-client-router-or-client-os-blocking-outgoing-vpn-4175685170/)

Firewall (client router or client OS) blocking outgoing VPN?

My colleague cannot access our office PiVPN from her home but I can on my laptop from my home.

So by outgoing VPN, I mean the client trying to connect to the VPN server here, and something inbetween is maybe blocking it.

We successfully tested both laptops (both Linux) at the office going online through a mobile hotspot from my phone, and both had access, so I guess client settings on her laptop should be fine, but I was thinking maybe my colleague's router at home could block her outgoing VPN from reaching the Pi at the office, is that possible? If yes, what settings would I need to check on that router?

Both clients are configured using OpenVPN.
I've also seen reports of Windows firewall blocking clients' VPN, so I thought it might be something on my colleague's OS (Lubuntu 18.04) that's blocking it?

Quote:

We successfully tested both laptops (both Linux) at the office going online through a mobile hotspot from my phone, and both had access, so I guess client settings on her laptop should be fine, but I was thinking maybe my colleague's router at home could block her outgoing VPN from reaching the Pi at the office, is that possible? If yes, what settings would I need to check on that router?

It might be helpful to provide the router brand and model in order to provide a meaningful answer here. The ISP in question as well. Since your colleague's laptop VPN connection works from another network environment, it does point toward the router (or ISP) blocking of the OpenVPN port required for connectivity.

Quote:

I've also seen reports of Windows firewall blocking clients' VPN, so I thought it might be something on my colleague's OS (Lubuntu 18.04) that's blocking it?

It's unlikely to be a Linux firewall, as these usually only block unsolicited incoming traffic by default.

It is a ZTE router provided from 3 Austria, branded "3 Webgate" probably 3rd iteration: https://maxwireless.de/2014/3webgate...zte-gefertigt/
I found there is a thing called VPN passthrough, apparently a feature when the router allows it. I haven't been able to find a setting for it though on my Huawei B593s-22 router, which is not blocking my VPN client from going out.

EDIT: I'm on the router's web interface now, and it doesn't seem to provide any setting for enabling VPN passthrough. It also isn't showing any new available firmware

Quote:

It is a ZTE router provided from 3 Austria, branded "3 Webgate"

So, translating the link you gave to English, I came to understand that it is an LTE modem

Quote:

I found there is a thing called VPN passthrough, apparently a feature when the router allows it.

That really only applies to older VPN protcols such as PPTP and L2TP. See here...
https://nordvpn.com/blog/vpn-passthrough/
Not relevant for OpenVPN. Is your server listening on port 1194, or some other? Perhaps check that this router isn't blocking outgoing connection on that particular port.

There is a chance that it is MTU related, specific to the router/ISP network. This would explain why there were no issues during the testing via another network. Sometimes it is necessary to tune maximum MTU on the client end (tun-mtu parameter in client config) to prevent packet fragmentation occurring. Mentioned here...
https://forum.netgate.com/topic/9288...t-not-4g-lte/7

From the OpenVPN Reference Manual...

Quote:

–tun-mtu n
Take the TUN device MTU to be n and derive the link MTU from it (default=1500). In most cases, you will probably want to leave this parameter set to its default value.The MTU (Maximum Transmission Units) is the maximum datagram size in bytes that can be sent unfragmented over a particular network path. OpenVPN requires that packets on the control or data channels be sent unfragmented.

MTU problems often manifest themselves as connections which hang during periods of active usage.

It’s best to use the –fragment and/or –mssfix options to deal with MTU sizing issues.

I'm not sure if I understood how to set the tun-mtu option.
It's supposed to go in the .ovpn configuration file that I generated on the server and imported to the client, yes?

Mine looks like this:

Code:

client

dev tun

proto udp

remote 84.113.65.254 1194

resolv-retry infinite

nobind

persist-key

persist-tun

key-direction 1

remote-cert-tls server

tls-version-min 1.2

verify-x509-name server_aLWlH75WJRHF1pfF name

cipher AES-256-CBC

auth SHA256

auth-nocache

verb 3

<ca>

-----BEGIN CERTIFICATE-----

blablablablablablablablablablablablablablablablablablablablablabla

would I just put something like

Code:

mtu-tun 1300

below <ca>?
Also, I'd have to re-import that file then? I did it with the network-manager GUI.

Maybe I should mention that on my phone I have the same ISP/carrier as the offending LTE router, and I can connect over that too, using my phone as a mobile hotspot.
If I understand your suggestion about the mtu setting correctly, I should do this in the client config, which means nothing changes on the router. If MTU size is the problem, but I can fix it on the client, how does the router or even the ISP factor in?

Quote:

Maybe I should mention that on my phone I have the same ISP/carrier as the offending LTE router, and I can connect over that too, using my phone as a mobile hotspot.

Ok, that's good info (and I meant to suggest checking via such a hotspot anyway). This really only leaves the router as the cause. MTU size was only something to check, but perhaps it is the ZTE router which blocks the port used with OpenVPN connectivity. From the client config I note that you're using port 1194 UDP. I can't advise any further about the ZTE router, but assuming that you're the administrator of your VPN server, it may be acceptable to have it listen on port 443 instead. You would need to know if this port is already being used for other web service behind the corporate firewall though. Anyway, have a read...

https://openvpn.net/vpn-server-resou...-command-line/

Quote:

By default the OpenVPN Access Server comes configured with OpenVPN daemons that listen on port 1194 UDP, and OpenVPN daemons that listen on port 443 TCP. While the best connection for an OpenVPN tunnel is via the UDP port, we implement TCP 443 as a fallback method. It is likely that if you are on a public network that Internet connectivity is restricted. But TCP 443 is the port used for HTTPS traffic, and a lot of websites use HTTPS by default. So by having an OpenVPN TCP daemon on port TCP 443, chances are that even on such a restricted network your OpenVPN client program will be able to make a connection to the OpenVPN Access Server using the TCP fallback. It’s no guarantee since some firewalls are quite sophisticated and can see the difference between a web browser and an OpenVPN client program, but it works on most simple firewalls.

As mentioned, TCP 443 is also used for HTTPS traffic, which the web interface of the OpenVPN Access Server also uses. You cannot have 2 different processes listening on the same port on the same server, so we use something we call service forwarding or port sharing. When you open the web interface of the Access Server on its default TCP port 443, the OpenVPN TCP daemon sees that request and recognizes that it is a browser request. It then internally redirects the traffic to the web services which are actually running on port TCP 943. When you change which interface the OpenVPN daemons listen on, you could be inadvertently denying yourself access via this port forwarding method. The solution then is to use the port that the web services are actually running on; TCP 943. To access the web interface at that port put :943 in the URL like so: https://your.vpnserver.com:943/

Warning: changing these values may mean you have to reinstall your clients in order to be able to make a connection again, as these settings do not update automatically on the clients.

Thanks for these informations!
The server is a Raspberry Pi running PiVPN, and I am the administrator of the small office network that we're trying VPN into.
Now there is a lot about of ports mentioned, but unfortunately I seem to have a poor understanding of how this works, because: port 443 on which device? There are three (maybe 4?) devices here this could be referring to: the client, the server and the client-side router (and maybe also the server-side router)? My understanding - correct my if I'm wrong - is that traffic can go out from one host (e.g. the VPN client) through any port and arrive at its destination (e.g. the VPN server) through an entirely different one...?

Quote:

Originally Posted by ferrari (Post 6185319)

You would need to know if this port is already being used for other web service behind the corporate firewall though.

emphasis mine.
So what I'm asking is: this port on which device? If you're talking about the RPi, it's not used for anything else but for managing the PiVPN.

Btw my colleague said if the router was the problem and we can't fix it on this device, she could just get a newer model from the ISP/carrier. Could this solve the problem? If yes, what specification of the new router would we need to look out for?

Worth a shot I guess, but I can't/won't promise anything here. It's already a surprise to me that it would block outgoing traffic on that port. You could examine the client OpenVPN logs to get a better idea on what is happening. Since your colleague uses NetworkManager, you could open a terminal and run

Code:

sudo journalctl -fu NetworkManager

before trying to connect. Observe the output to see what's failing during the connection process.

Just my $.02 :twocents:
I once had an ISP (satellite) that disallowed ANY continuous connections through their service unless you paid through the nose for that service. I could connect sometimes with ssh for seconds and sometimes not at all.
I wonder if the problem here may be similar.

You have said that connection works through your mobile hotspot so it is not configuration of the client that is affecting it. That leaves only the router or isp to interfere.

Maybe try a different router, or talk to the ISPs tech support, or both.

I did a cross-over test, using both my and my colleague's laptop to connect to the PiVPN over both my and my colleague's LTE router.
Both laptops get a connection over my router, and both laptops fail to connect over her router.
Would you guys agree this is proof that the router is at fault?

Quote:

Originally Posted by bennypr0fane (Post 6187756)

I certainly would agree that is a possibility. You have not said anything about firewall/port forwarding, or anything else that could be pertinent in her router config as compared to yours.

I would suggest that you do a detailed comparison of the router configs and see if you can identify any differences that might affect the vpn. To see if it is firewall related a (short term) disabling of the router firewall could be one troubleshooting step. It could also be a simple IP or domain blockage on the parental control part. Or any one of several other possibilities that will require checking individually to identify.

I just meant that I can stop worrying about what might be wrong on the client, as the config there is working. Now finding out what setting in the router is causing problems is going to be hard, because these routers provided by the ISPs have branded firmware that is pretty locked down and won't really let you see all that much, let alone tweak things to your liking. Mine for instance won't show me a list of connected devices... If my colleague is finw just getting a newer router, I guess I won't object...
But suppose I did manage to take another shot at the router, what would you look at first?