How to use a Wireguard Server and an OpenVPN client at the same time?

This is by design. Your data goes one way or another.

You need to use vpn policy and do not use vpn for “all process on the router”.

Did that but changed not the behavior of DDNS…

is there no other way to bypass the VPN for the Wireguard connection?

So, I did try to reconstruct the situation on my dd-WRT router and both connections work simultaneously.

For the OpenVPN client I did some Policy Based Routing so only a certain IP range (x.x.x.100 to x.x.x.150) shall get routed over the OpenVPN connection and the rest is normally connected to the WAN.
For Wireguard I didn’t change anything and I can establish a WG connection via LTE to my home network at the same time.

so your statement “Your data goes one way or another.” may be true on the GL router but in reality it’s no big deal to get this working

actual settings on the GL-MV1000W
VPN Policy settings:
Use VPN for all processes on the router → deactivated
Policy: Domain/IP
Rule: Only allow the following use VPN: 192.168.0.101

if I activate the the Wireguard Server the following error prompts: WARNING: Conflicts! All other VPN services must be stopped first.

So I have proven that this setup works on a dd-wrt router, so technically this setup works, is there something I can change in the openWRT setup?

BTW DDNS Service is also runnig on den dd-wrt if openVPN and Wireguard is running…

any comments @alzhao as you are entitled to be of the Technical Solutions Team

DDNS should just work fine. I am not sure why not. You can send me a message and add my skype for detailed discussion.

The UI just does not accept two VPN connections, by design. You need to ssh to the router to configure manually if you do want.

OK DDNS should work with proper VPN Policy setting (only allow VPN for certain IPs)

But in case of the issue with the OpenVPN Client and a simultaneous Wireguard connection you should reconsider your “design” because in this case your device will not suit my requirements/ use case.

As this is something which is in direct regards to the GL.Inet UI you might think about changing this restriction because it is useless and reduces the functional range of the device…

to be honest, I bought the BRUME just for exact this use case because I thought this device can handle my needs withe ease.

For advanced features it does work, just not out of the box. The router “by design” has the most used configurations that people use. It is impossible to supply a router that can have all combinations (especially for fringe use cases). It’s not a hardware issue, its a software configuration issue only.

You can set up your own iptables routing to get it to work. For such more advanced things, you are better off asking in the OpenWRT forums. Here is an example of someone doing what you want:

You should also not be using OpenVPN in 2020, it is slow on the travel routers as it uses AES that is only software decoding. Get VPN provider that has Wireguard instead.

Wireguard is not supported by most of the VPN Providers…so I do need OpenVPN

We have a list of 12 providers that support Wireguard here:

Your provider must not be very good then?

I don’t think we have a comparable opinion what “good” is. I need to trust my VPN provider, I don’t care if it implements the latest technologies. My first priority is privacy and that is what matters, not if the used protocol is the newest standard. What if my VPN provider leaks user data, as there have been now not a few which have done that, but uses Wireguard… A good VPN Provider is not awarded by the use of the Wireguard Protocol…

You should also not be using OpenVPN in 2020, it is slow on the travel routers as it uses AES that is only software decoding. Get VPN provider that has Wireguard instead.

I bet to differ. You should have Openvpn VPN as part of your arsenal especially a travel router. I have connected to many providers where UDP ports are blocked. Openvpn can connect over TCP.

You will not convince me to change my provider, go and use what ever you like to. It’s my decision not yours.

@sammo It’s very easy to tunnel wireguard over TCP. There will be a solution for that soon, keep your eyes open for it.

@tomron As i wrote before, you can route your connections as you want, search the OpenWRT forums or start a thread there for more help.

So from the wireguard web. The standard protocol does not support TCP and have to implement a workaround. How many vpn providers going to provide workaround?

TCP Mode

WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard’s UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.

Will be our service, can be used with any provider :slightly_smiling_face:

The only way this would work is you are becoming intermediate agent and provide obfuscation servers. This effectivity means you are providing a VPN service. Why would I want to handover my data to another party? I hope you have the bandwidth/speed or it will end in tears.

I have to admit, it makes always good feeling for the customer, if you redirect your customers to another support forum

Since the routers use open source software, and the official forums for that software are full of people that know what they are doing on a low level, why would we not redirect users to it?

Since the routers UI restricts this function which is allowed in the open source software (openWRT) its not the duty of the customer to find a workaround in another forum, sorry we have a different sense of what customer support shall provide.
Item will get sent back to Amazon…

I have no idea of what is your logic.

In the UI it is not allowed and then it is not allowed. We cannot provide customer service to allow that.