I’ve installed the openvpn-as docker container. On the guide page the default credentials are admin/password. When logging in the webgui i recieve the following error;
SESSION ERROR: SESSION: Your session has expired, please reauthenticate (9007)
How can i reset the admin credentials without having access to the webui?
More people has this issue, but the given fix is using an older version https://www.reddit.com/r/OpenVPN/comments/f8z7cf/just_installed_openvpn_cant_login_as_admin/
That was the trick, thanks!
That didn’t do the trick for me.
I have installed Openvpn-as with the “official” docker compose from the doc on https://hub.docker.com/r/linuxserver/openvpn-as
and I get this problem.
To quote you @aptalca:
That error happens when either of the following occurs:
iptables issues on host (either not installed or missing kernel modules)
you didn’t add cap-add NET_ADMIN
you’re using an unsupported networking method (host or macvlan)
Firewalld might be the issue then. Not sure, but I think you have to manually configure it for docker to work. Also, did you install docker from the fedora repo or docker.com?
firewalld is not iptables. you can remove firewalld and install iptables (docker works with iptables) or manually create the rules in firewalld as saarg mentioned.
this is a tad dated but still accurate if you want to learn about the difference.
I’m not sure what this had got to do with iptables actually.
I mean docker IS working with other container. And if I stop firewalld, the behavior of openvpn-as is just the same.
I’m using Docker CE from its own repo.
As far as I remember Firewalld is not using iptables behind the hood (anymore) but fedora still provides some sort of porting so you can list netfilter rules with iptables.
I’m pretty sure I shouldn’t have to fiddle with iptables rules manually. Docker forwards ports, ports are open on the main host. What else is needed?
Why would iptables hamper the Admin login process when the User login just works?
Openvpn-as needs iptables access (and the necessary modules enabled) otherwise it doesn’t run (as you experienced). It’s an openvpn-as requirement, not docker. Cap-add net_admin is what allows openvpn-as to access iptables on host
In previous versions, it would let you login to the admin interface but would display an error inside and wouldn’t be able to start the server. I don’t know why they changed that behavior because that was a lot more descriptive than just blocking logins. Probably a side effect of something else and not an intended behavior change.
Any idea where I should be looking for iptables error within the Docker image?
The docker openvpn-as log doesn’t show anything
type firewall-cmd --state on your host
if it says active, you aren’t using iptables and that is your issue.
I mean, sure, firewalld is there. I’m not willing to remove it from Fedora really, it’s part of it.
Iptables cmd is here and working so I thought it’d be just working.
I remember somehow that it’s here only for compatibility at some level, and probably shouldn’t (or cannot even) be used to change the rules behind firewalld’s back.
I tried to disable it and install iptables-service but it messes up with other stuff installed.
It feels really weird that this Docker’s cap_add directive doesn’t work on some linux instance.
I could find anything about it not working on Fedora on the web.
Maybe this is consistent with RedHat pushing for their own container mgmt, what with other problems like cgroups v2 not compatible with docker…
Anyway, I give up here and will do a std install. I’m usually using debian/ubuntu, just wanted to try Fedora on that server … damn 
redhat does have some documentation on how to work around docker issue, they understand that they are the cause of the issue, sadly it extends to all RHEL derivative distributions.
most searches will tell you to disable firewalld and use iptables, but you can definitely make the rules manually and still have success. as for the political motivations, you could very well be right, but I don’t really follow all that enough to comment.
as to the comment about iptables being present, firewalld overrides it if it’s in an active state. if you want to use iptables, you must deactivate firewalld, but again, you can create the rules manually if you love the ease of firewalld.
I just tried an install on a fresh Ubuntu 20.04 and I get the same problem.
I tried the most direct docker install (apt install docker.io, Docker version 19.03.8)
iptables seem to be up and working as expected:
~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.18.0.2 tcp dpt:9443
ACCEPT udp -- anywhere 172.18.0.2 udp dpt:openvpn
ACCEPT tcp -- anywhere 172.18.0.2 tcp dpt:943
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
What else could be the cause?
can you share your compose and docker logs again? I know @aptalca mentioned he hadn’t done something for focal yet with wireguard, not sure if that extends to openvpn. I know we have some members working in the background to prep everything for focal but i doubt we’ve tested much with it. That said, ubuntu and debian are usually the ones that “just work.”
I almost want to say give up on openvpn (because it sucks) and move to wireguard, but you put so much into various testing setups I feel committed to root causing this baby.
thanks, it’s not like I would give up so easily anyway
I’m using wireguard but I also need openvpn actually. Some Set-top_box I need to support…
This is why I couldn’t easily disable firewalld on Fedora, Wireguard somehow was dependent on it.
I want to try to use linuxserver.io Wireguard docker setup as well.
See docker-compose logs here Attaching to openvpn-as[36mopenvpn-as |[0m [s6-init] making user provided - Pastebin.com (just same ad docker logs)
The only weird thing I can notice is:
e[36mopenvpn-as |e[0m Error: Could not execute 'systemctl enable openvpnas' to enable startup/shutdown scripts
e[36mopenvpn-as |e[0m Stopping openvpn-as now; will start again later after configuring
e[36mopenvpn-as |e[0m cat: /var/run/openvpnas.pid: No such file or directory
e[36mopenvpn-as |e[0m kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
When I think of it, I think it was the same on Fedora. I will double check this.