openfortivpn
openfortivpn copied to clipboard
adrienverge
Invalid session ID error when trying to connect from a different network
I am trying to connect to the VPN from a different network (I am visiting another country), and I get the following error:
ERROR: SSL_connect: error:0A0003E7:SSL routines::invalid session id You might want to try --insecure-ssl or specify a different --cipher-list
The VPN connection works properly when I do it from my home network, and if I connect to it using Wireguard, then the VPN connection gets established (then it shuts down, I guess because there may be some routing issues with the nested VPNs). So it looks like something in the network I am is somehow causing this "session id" error. I tried with "--insecure-ssl", and other ciphers, but it does not help.
This is the result of the log with "-v -v -v", but it does not seem very informative. vpn.log
I am using the Openfortivpn package included with Debian Bookworm (1.19.0-2).
Which country are you visiting? This country may have a "great firewall" that forbids VPN connections.
Which country are you visiting? This country may have a "great firewall" that forbids VPN connections.
It's Germany, so I would be a bit surprised about such a firewall. I am at an academic institution so I would be also surprised if they were blocking VPNs. They do not seem to be blocking HTTPS traffic. Would there be a way you know of to make sure if it's a network block or another issue?
I tried to use my phone connection (sharing it with my computer as a WiFi hotspot), and it worked, so I am guessing there may be some blocking in the network. I wonder if there may be workarounds...
I guess it's not a "great firewall", but it might be another security appliance at the institution you are visiting, which does deep packet inspection on https traffic. If that's the case, workarounds are difficult. Which one is the winner? The VPN which tries to protect your traffic or the appliance, which tries to protect the network you are on against uncontrolled traffic? ;)
Maybe there are different wifi networks with different policies, so switching to another one might solve the problem. If not, maybe talk to the network security department of the institution. Perhaps they have a solution at hand (if they are really doing deep packet inspection).
Another possibility could also be an attacker who operates another wifi with the same SSID and tries to fish the credentials. In that case it would be the right thing that the vpn connection doesn't get established.
The difference between the two cases is just if it's a good guy (security staff) or a bad guy (attacker) who is trying to inspect your ssl vpn traffic. The security staff might trust your home organization and configure an exception for your vpn connection. If it's not them doing deep-inspection, they are probably thankful for the hint and want to have a closer look what's going on in their network ;)
But it's perhaps not that exciting. It could also be something simpler, like packet fragmentation in combination with wrong mtu settings or so, which breaks the establishment of the ssl connection
Many institutions, including academic ones, forbid the use of VPNs from their internal network on purpose, for obvious reasons. They may also inadvertently disable VPNs on visitors' networks.
Was your computer connected to the internal network of an academic institution, or an external network such as Eduroam?
It's been a while since I left that place, and I managed to connect through other networks (I was connected via eduroam in that place), so I will close this issue as it seems moot now.
There was probably no deep packet inspection or VPN blocking involved on Eduroam... but it's too late to investigate :smile:
I may get back there in the future. If that happens again I'll come back here to get some tips on how to investigate. :-)