Openvpn-as default admin credentials won't work

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

See here: Just installed openvpn-as can't 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
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)
  • cap-add NET_ADMIN is part of the docker config so that’s not it.
  • iptables seems to be working as expected, how could I double check? (the host is Fedora and using firewalld)
  • as per the config provided on the official docker documentation, which networking method am I using? I am not clear about this.

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

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.

1 Like

thanks @aptalca, makes sense now, will be looking into this.

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 :slight_smile:

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 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              tcp dpt:9443
ACCEPT     udp  --  anywhere              udp dpt:openvpn
ACCEPT     tcp  --  anywhere              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 :slight_smile:

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 Wireguard docker setup as well.

See docker-compose logs here (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/ 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.