[SOLVED] Wireguard: Peer to server hangs over 3g or qmi-wan interface

Is anyone using wireguard over qmi-wan/3g interface?
On Turris Omnia, any connection from the peer seems to hang
Direct access (i.e. not through wireguard) works fine for both ssh and http access through the 3g or qmi-wan interface. The configuration works as expected on the same machine when wan interface is used.

The issue is easily reproducible, just setup wireguard through the qmi-wan/3g connection and use ssh from the wg peer to connect to the wg server. After the connection, issue an eg. htop command and the connection hangs. It also hangs if you cat a text file. Http access to the TO from the wg peer is not possible.

Have you worked on your entropy issue, as noted in the other thread?

You also didn't address the multiple interface question, you only stated you had mutiple peers.

Yes, as i mentioned I Installed haveged.

root@Turris:~# sysctl kernel.random.entropy_avail
kernel.random.entropy_avail = 1865

Sorry for missing it but I only have one wg interface. The entropy above is for one interface with one peer connected.

1865 is still low!

  • Especially when standing up an SSH connection that must produce a session key

You are probably right. On an espressobin, I also run openwrt and the the entropy with one peer connected is kernel.random.entropy_avail = 2489.
What is not clear to me is why on Turris Omnia the same configuration works perfect through the wan interface even if entropy is kernel.random.entropy_avail = 1865 but it fails through the 3g/qmi-wan interface.

BUMP
I am on the latest snapshot. Entropy now seems good.
Traffic from server (openwrt-turris) to the peer is fine.
The http problem from peer to server persists

OpenWrt SNAPSHOT, r8614-78ca6a5
 -----------------------------------------------------
root@Turris:~# sysctl kernel.random.entropy_avail
kernel.random.entropy_avail = 2079`.

here is the response that I get from turris (server) when i try to connect to luci from the peer:

192.168.10.4.50214 > Turris.lan.80: Flags [P.], cksum 0xa26f (correct), seq 525:979, ack 187, win 237, options [nop,nop,TS val 1146513774 ecr 1676346658], length 454: HTTP, length: 454
	GET /cgi-bin/luci/ HTTP/1.1
	Host: 10.0.10.1
	Connection: keep-alive
	Upgrade-Insecure-Requests: 1
	DNT: 1
	User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/70.0.3538.110 Chrome/70.0.3538.110 Safari/537.36
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
	Referer: http://10.0.10.1/
	Accept-Encoding: gzip, deflate
	Accept-Language: en-US,en;q=0.9,el;q=0.8
	
03:18:14.927215 IP (tos 0x0, ttl 64, id 31922, offset 0, flags [DF], proto TCP (6), length 128)
    Turris.lan.80 > 192.168.10.4.50214: Flags [P.], cksum 0xdf1f (incorrect -> 0x41a2), seq 187:263, ack 979, win 231, options [nop,nop,TS val 1676346872 ecr 1146513774], length 76: HTTP, length: 76
	HTTP/1.1 403 Forbidden
	Connection: Keep-Alive
	Transfer-Encoding: chunked
03:18:14.928116 IP (tos 0x0, ttl 64, id 31923, offset 0, flags [DF], proto TCP (6), length 1420)
    Turris.lan.80 > 192.168.10.4.50214: Flags [.], cksum 0xe42b (incorrect -> 0xeb14), seq 263:1631, ack 979, win 231, options [nop,nop,TS val 1676346873 ecr 1146513774], length 1368: HTTP

Any idea how to debug this?

I am certain that there is no problem with the peer. I have two other networks connected on the same wireguard interface (one using openwrt) and everything works fine.

Yes, provide entropy results after attempting to connect. Making encrypted connections lowers entropy, as traffic is continually encrypted!

Also, does your deice have an Atheros ath9k wireless card in it enabled?
Where are you obtaining entropy from?

Also, I really don't see anything in the course of the 2 packets you displayed, especially since you didn't show if they were seconds apart, etc. (since the first timestamp is missing)...

Finally I managed to solve the problem.
This was not related to the entropy.
After reading this and this posts, I started looking at the firewall. Restarting the firewall from the command line was producing an output:

! Skipping due to different family of zone

So I changed the firewall settings (originally being as proposed in other posts here) and everything works fine now.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.