Wireguard via WWAN interface

Has anyone managed to configure Wireguard properly via the WWAN interface or is this not provided?

I struggled for a long time, it partially worked, but it keeps falling off ))

Well, that is, the router is connected to another router via Wi-Fi

Wireguard is interface agnostic.
When exactly it keeps falling off ?
Show your network config file along with the relevant fragment of the system log.

1 Like

And you try to do it yourself if you can, my configuration won't give you anything, just conduct the experiment yourself if you can

I struggled for a month

Keep trying then.

2 Likes

and I just asked, maybe someone succeeded, well, you never know, what if ))

I used the most advanced AI, forums and other things, and you're asking me about configuring)

Try it yourself and you won't succeed, I'm 200% sure

1 Like

Wireguard does not care about the interface, but mobile ISPs tend to be more limiting (starting with cgNAT and quite a bit of filtering on the well-known ports).

2 Likes

I would agree with you, but I can't. I do use amneziawg, but it's based on wireguard, so it's essentially the same thing.

1 Like

Enabling persistent-keepalive should help with keeping the tunnel up for long durations through cgNAT. https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence

@fkl7834456 Does the WireGuard tunnel "fall off" while packets are actively flowing through it or after it has been dormant for a period of time? Try setting Persistent Keep Alive to 25 for the peer you're connecting to.

Try doing it yourself. Connect the router with WireGuard to another router via WWAN, that is, via Wi-Fi. You've never tried it before. Try rebooting the router, etc.

I've been struggling for a month now, and I've partially succeeded. It works, but it's clumsy.

The funny thing is, when everything seems to be working, you think, well, that's it, but you come in the morning and it doesn't work again )) it's mystica l

It worked for three days, you think, finally, but on the fourth day it doesn't work ))

and it works perfectly through a regular WAN cable

Explaining what WWAN is, would probably help.

1 Like

Nobody can help you, if you don't post your settings,

It's like everyone before me said, wireguard won't care about your interface, wwan, wan, lan, etc

1 Like

Wireless WAN.

Yeah, well, we're going to need more than that.

1 Like

It’s not clear how your wireguard setup is intended to be used — is it as a ‘server’ listening for inbound connections? Or a ‘client’ to connect to a remote system?

Do you control the upstream WiFi network?

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Screenshot 2025-10-20 at 8.14.14 PM

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall

That is why the watchdog scripts exist even connected by wire a server is sometimes down or moved, I use a watchdog script with failover which connect to a different server when the server is down :slight_smile:

Yes, I've ran a Wireguard tunnel thru a Wireless WAN for years. It's definitely possible. Same as any other Wireguard setup, 200% sure.

1 Like
Wohever doesn’t know might want to google “STONITH”

15 years ago, I had a 3HE storage unit from Supermicro housing two independent servers. In addition to whatever connectivity a server had back then, both were connected by a very short point-to-point network for heartbeat, and each of the servers had an extra physical device to power the other server off. Back then I learned about STONITH.

The box was full of SAS drives, and each drive was connected to both servers. Each server ran half of the drives in a ZFS pool but could technically “see” the other ZFS pool. Whenever the other server went “unseen” (unresponsive to heartbeat), each server was configured to immediately “shoot it down” by its “power button device” and start mounting the second ZFS pool.

As of staying on topic:

Is your OpenWrt box waiting for incoming connections (“server mode”), or is it initiating the connections (“client mode”)?

I suspect you run WireGuard in “client mode”. And I suspect your “regular WAN cable” is not connected to the OpenWrt device that uses WWAN as uplink, but to the upstream router your WWAN is wirelessly connected to.

The current working theory is: It’s not the WWAN interface that’s causing problems, and not even the networking of your OpenWrt box, but the NAT configuration of the upstream server your OpenWrt is connected to.

WireGuard is UDP, not TCP. This means there is no “connection” that could have a “state” and suddenly “disconnect”, but just traffic packages. When a device inside a network initiates a connection to the outside, this traffic goes from “local source port A to remote destination port B”, and it is expected to have the return traffic come “from remote port B to local A”. Speaking of WireGuard, B would be 51820 by default. As long as a router doing any kind of NAT remembers the “from A to B” pair, it can derive: “yep, this incoming traffic is meant for this locally connected device”.

This works as long as there is constant outgoing traffic, which tells the NAT router to keep remembering the “from A to B” information. Once you stop producing outgoing traffic “from A to B”, the NAT router might just decide to forget the “from A to B” pairing, and when there’s return traffic “from B to A”, the NAT router is no longer able to derive the internal device as the actual destination after NAT.

This is where the “persistent-keepalive” setting comes into play. Your own WireGuard instance will constantly produce traffic to the other WireGuard node, and the other WireGuard node will respond. This should make every NAT along the way keep remembering the port pairs. That’s true for both carrier-grade NAT as well as additional NAT you introduce yourself by setting up “a router behind a router”.

2 Likes

ou know, the problem is somewhere further on.
That is, there is a problem with the router I am connected to.
o i want to apologize, I shouldn't have raised a fuss.
and I still haven't solved the problem, I don't even know :slight_smile:
but thanks for listening