Cannot access an external Wireguard peer on my Wifi

Installing and Using OpenWrt
1

I have access to a WireGuard peer outside of my LAN. It runs on udp/500. When my phone is connected to my LAN's WiFi, I am unable to connect to this external peer (from the phone). If I drop off my WiFi and use LTE, connections work as expected. If my phone is connected to other WiFi networks, connects work as expected.

  • Since the connection is outgoing from my router, I should NOT require forwarding a port.
  • The only traffic rule I have in place acting on port 500 is the default, "Allow-ISAKMP."

Why can't my phone connect to the WireGuard peer hen it is connected to WifI?

18.06.5/R7800

2

Maybe there is something in the logs?
logread -f and try to connect.

Otherwise make sure packets go in and out:
tcpdump -i any -vn udp port 500
Post here what you see.
You can cover public IPs, MAC addresses etc.

I hope the remote network does not conflict with the local at home. That means if you have 192.168.1.0/24 at home, the remote is not 192.168.1.X as well.

1 Like
3

I get nothing from logread -f when I try to connect.

The two networks do not conflict (my LAN is 10.9.8.x and remote is 192.168.x.x)

Here is the tcpdump output (I blanked out some of the IP addresses as you said):

# tcpdump -i any -vn udp port 500
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
07:48:04.074129 IP (tos 0x0, ttl 64, id 2903, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 14.11 msgid 9d2e48e9:
07:48:04.074129 IP (tos 0x0, ttl 64, id 2903, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 14.11 msgid 9d2e48e9:
07:48:04.074229 IP (tos 0x0, ttl 63, id 2903, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.59623 > xxx.xxx.175.0.500: isakmp 14.11 msgid 9d2e48e9:
07:48:09.359625 IP (tos 0x0, ttl 64, id 35154, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 8.0 msgid 6ee196c6:
07:48:09.359625 IP (tos 0x0, ttl 64, id 35154, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 8.0 msgid 6ee196c6:
07:48:09.359734 IP (tos 0x0, ttl 63, id 35154, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.59623 > xxx.xxx.175.0.500: isakmp 8.0 msgid 6ee196c6:
07:48:14.533773 IP (tos 0x0, ttl 64, id 28956, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid 95942e60:
07:48:14.533773 IP (tos 0x0, ttl 64, id 28956, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid 95942e60:
07:48:14.533841 IP (tos 0x0, ttl 63, id 28956, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid 95942e60:
07:48:19.815850 IP (tos 0x0, ttl 64, id 9201, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 2.13 msgid 0fc5a900: child_sa  #55[I]: [encrypted #211] (len mismatch: isakmp 3140593600/ip 148)
07:48:19.815850 IP (tos 0x0, ttl 64, id 9201, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 2.13 msgid 0fc5a900: child_sa  #55[I]: [encrypted #211] (len mismatch: isakmp 3140593600/ip 148)
07:48:19.815918 IP (tos 0x0, ttl 63, id 9201, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.59623 > xxx.xxx.175.0.500: isakmp 2.13 msgid 0fc5a900: child_sa  #55[I]: [encrypted #211] (len mismatch: isakmp 3140593600/ip 148)
07:48:24.995063 IP (tos 0x0, ttl 64, id 8278, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid fdbb0039:
07:48:24.995063 IP (tos 0x0, ttl 64, id 8278, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid fdbb0039:
07:48:24.995182 IP (tos 0x0, ttl 63, id 8278, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.59623 > xxx.xxx.175.0.500: isakmp 0.15 msgid fdbb0039:
^C
15 packets captured
77 packets received by filter
7 packets dropped by kernel
4

I'm confused...

  • Are you saying that Wireguard works as expected from your cell; but doesn't work when you test Locally on WiFi?
  • Why are you using port 500?
  • Why didn't you choose another port, and make your own rule?
  • Does the existing rule and firewall config allow 500/udp from LAN?
5

@lleachii - Yes, when my phone is on LTE or connected to a different WiFi (public places), the WG connection works as it should, but when I get home and my phone connects to my WiFi network, WG on the phone does not work.

Also, I am using port 500 to maximize connections on public WiFi networks. Some of them block the stanard port 51820 but running on 500 works fine.

An update - I changed the port on the WG peer (server) from 500 to 51820 for testing purposes. Again, when my phone is on LTE, I can connect with WG on this port, but when I connect to my WiFi network, and then attempt to connect, no data seems to flow :confused:

6

So to be clear...

  • The phone is a peer?
  • The OpenWrt is the server-peer?

(If so, I don't yet understand your saying you didn't need to open ports, yet a 500/udp port rule exists.)

  • FYI, you don't have to pick 51820
  • Can you explain why you're testing locally?
  • Again, have you verified your current firewall config permits input from LAN on 500/udp; and did you change the hostname in your cell to the LAN IP for testing
7

The phone is a peer.
OpenWrt is not a peer. It is just serving up my home WiFi.
The WG "server" is a remote PC hundreds of miles away from my physical location.

What I cannot understand is why the phone (wireguard app) works as expected on LTE or on public WiFi network but not from my home network. Home router is a R7800 running OpenWrt.

I haven't changed the hostname in the cell to the LAN IP... I don't think that is needed (unless the WG app does this behind the scenes).

8

OK.

Cell <> Mobile_ISP <> WG_Server == working
Cell <> OpenWrt <> Internet <> WG_Server == not_working

...so why is this an OpenWrt inquiry? (i.e. are you aware of any configs you made to prevent?) Maybe your ISP blocks that.

  • Have you tried removing/disabling that firewall rule
  • Be certain you didn't assign a port of 500 to the cell, only your server needs a port - this may cause an odd problem if your firewall issues port 500 on WAN for NAT - because of your rule!

There's not many methods I'm aware of to identify the OpenWrt as the issue, without another known-working OpenWrt. I can say that I've never had such problems. My only guess is your LAN/WiFi and tunnel have the same IPv4 subnet addressing?

Can you test connecting to a neighbor's AP with:

  • Same ISP, different router
  • Perhaps they can let you plug your's in downstream and test via your WiFi

Huh...Nevermind anyways. No, you wouldn't change the hostname - I thought your OpenWrt was involved here.

9

This comes down to packet tracing. The above dump doesn’t say which interface and probably doesn’t show WireGuard packets.

1 Like
10

I think I've ruled out my firewall rules (OpenWrt) as the cause since I can connect to another separate WG server on the same port from the WiFi (again not 500 anymore but 51820). There shouldn't need to be any firewall rule since I am going out with the connection. I am at a loss to explain why the connection is not possible.

11

:confused:

I think you missed me (again) - no one mentioned creating a firewall rule.

I said disable:

  • I told you this is known to work, I tested WG connections thru OpenWrt APs; and did so for this thread
  • Are you sure you know what a "port" is, or are we referring to the cell?

OK:

Cell <> OpenWrt <> Internet <> xxx.xxx.xxx.xxx:51820 == working
Cell <> OpenWrt <> Internet <> yyy.yyy.yyy.yyy:500 == not_working

  • Yes, the firewall rule is still suspect! Did you disable it?
  • This also hasn't eliminated your ISP blocking 500/udp as the cause
  • Also, are you saying you followed my advice regarding you cell config:

Please be clear.

  • If you control the server, I highly suggest you consider not using 500/udp, pick any number from 1024-65635
  • Lastly, can we verify the packets are returning with a good tcpdump?
1 Like
12

@lleachii - Sorry for introducing confusion and thank you for engaging me on this thread (all the testing you're doing too)!

Let me try to simplify:

Yes, I control it. I selected port 43049/udp for the simplified situation, no more 500.

  • I made no assignments in OpenWrt referring to the cell at all.

Cell <> OpenWrt <> Internet <> yyy.yyy.yyy.yyy:43049 == not_working
Cell <> Internet <> yyy.yyy.yyy.yyy:43049 == working

  • There are no firewall rules on OpenWrt referring to port 43049 at all.
  • I cannot rule out the ISP as blocking 43049 but they (comcast on both ends) are pretty nonrestrictive in my experience.

Here is a dump I got running tcpdump on my home router running OpenWrt.

  1. Connected phone to wifi
  2. Connected WG app on phone to peer.
    Waiting a few sec them tried to browse the web. I saw no activity when I tried browsing so I am thinking the traffic in the dump is just the attempted hand shake but I am not an expert:
# tcpdump -i any -vn udp port 43049
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
11:49:46.084381 IP (tos 0x0, ttl 64, id 26866, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:46.084381 IP (tos 0x0, ttl 64, id 26866, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:46.084548 IP (tos 0x0, ttl 63, id 26866, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:51.373018 IP (tos 0x0, ttl 64, id 27478, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:51.373018 IP (tos 0x0, ttl 64, id 27478, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:51.373199 IP (tos 0x0, ttl 63, id 27478, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:56.547937 IP (tos 0x0, ttl 64, id 23661, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:56.547937 IP (tos 0x0, ttl 64, id 23661, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:49:56.548071 IP (tos 0x0, ttl 63, id 23661, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:50:01.841636 IP (tos 0x0, ttl 64, id 11788, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:50:01.841636 IP (tos 0x0, ttl 64, id 11788, offset 0, flags [none], proto UDP (17), length 176)
    10.9.8.167.63024 > xxx.xxx.175.0.43049: UDP, length 148
11:50:01.841788 IP (tos 0x0, ttl 63, id 11788, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.63024 > xxx.xxx.175.0.43049: UDP, length 148
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

EDIT: I will go to a public Wifi hosted by comcast now and try to connect with WG.

13

Guess this means mobile works.

I'm referring to configs in the cell, not the OpenWrt.
But nevermnid, as your trace gave me the answer.

:+1: I got this.

OK, this answered my question, you didn't configure 500 on the cell; and seems to solve what @jeff noted, since the port has changed to 43049...

I'll also note this is usually behavior of an improperly configured peer; but you state that you're only enabling WiFi.

Can you ping this WG Server IP from your OpenWrt router?

1 Like
14

Comcast here in the San Francisco area doesn’t block WireGuard. I’m not seeing any return packets in the dump. What do you see in the WireGuard status and logs on the server? What does running tcpdump on the server show?

2 Likes
15

The problem is that you are not getting anything from the WG server in return, although you are sending packets.
Check on the server side that you receive those packets, or if there is anything blocking them.

1 Like
16

That's right, with WiFi off, connections are possible, with WiFi on (my home) connections are not possible.

I tried from a friend's comcast WiFi and connections ARE possible so I'm thinking that means something my gear is doing is causing this.

The remote server on which WG runs does not respond to pings. I can ssh into it from a machine behind my OpenWrt router. I can attempt to ssh into it from the shell on OpenWrt but since the remote server only allows certain ciphers, I get this error:

# ssh myuser@remote.server.org -p xxxxx
ssh: Connection to myuser@remote.server.org:xxxxx exited: No matching algo mac c->s

I would have to compile wireguard on the server with debugging options to answer this. From the output of wg on the server, there is no connection.

interface: wg0
  public key: Rh14Aykq7hUryx7WKvQrfoSvz4TiDqDk/hHzbhhF@@I=
  private key: (hidden)
  listening port: 43049

peer: W4gkF2mEj27anOsk4PYKOIqlv3a/D9qB84xBTpew/mo=
  allowed ips: 10.200.200.2/32

This next piece is interesting:
My phone is connected to my home WiFi and I connect on the WG app. Here is the tcpdump on the remote server running WG which clearly shows my IP... what do we make of this?

# tcpdump -i any -vn udp port 43049
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:42:17.055370 IP (tos 0x20, ttl 50, id 56135, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.58241 > 192.168.1.120.43049: UDP, length 148
13:42:22.338232 IP (tos 0x20, ttl 50, id 8139, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.58241 > 192.168.1.120.43049: UDP, length 148
13:42:27.520091 IP (tos 0x20, ttl 50, id 23497, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.58241 > 192.168.1.120.43049: UDP, length 148
13:42:32.609610 IP (tos 0x20, ttl 50, id 42915, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.58241 > 192.168.1.120.43049: UDP, length 148
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
17

There is some address translation here.
You should be getting packets from xxx.xxx.108.23 to xxx.xxx.175.0.
However packets are destined to 192.168.1.120. Do you know what is going on at the server side? Is the xxx.xxx.175.0 the real IP of the interface of the server or is some NAT going on?

18

@trendy - I do not know... the xxx.xxx.175.0 is the real server IP (WAN) and 192.168.1.120 is the LAN IP of that server. All that dump is showing us I think is my home IP (WAN) to the server IP (LAN). I ran the tcpdump line as root on the remote server.

19

Here is the tcpdump trying to connect run on the remote router (DD-WRT) that shoss my IP (home WAN) connecting to its IP (WAN).

# tcpdump -i any -vn udp port 43049
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:24:25.354182 ethertype IPv4, IP (tos 0x20, ttl 51, id 44023, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:25.354182 IP (tos 0x20, ttl 51, id 44023, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:25.357519 IP (tos 0x20, ttl 50, id 44023, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:25.359296 IP (tos 0x20, ttl 50, id 44023, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:30.637016 ethertype IPv4, IP (tos 0x20, ttl 51, id 63801, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:30.637016 IP (tos 0x20, ttl 51, id 63801, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:30.639872 IP (tos 0x20, ttl 50, id 63801, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:30.641267 IP (tos 0x20, ttl 50, id 63801, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:35.804361 ethertype IPv4, IP (tos 0x20, ttl 51, id 22684, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:35.804361 IP (tos 0x20, ttl 51, id 22684, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:35.807219 IP (tos 0x20, ttl 50, id 22684, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:35.808615 IP (tos 0x20, ttl 50, id 22684, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:41.104174 ethertype IPv4, IP (tos 0x20, ttl 51, id 18263, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:41.104174 IP (tos 0x20, ttl 51, id 18263, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > xxx.xxx.175.0.43049: UDP, length 148
14:24:41.107031 IP (tos 0x20, ttl 50, id 18263, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
14:24:41.108426 IP (tos 0x20, ttl 50, id 18263, offset 0, flags [none], proto UDP (17), length 176)
    xxx.xxx.108.23.56302 > 192.168.1.120.43049: UDP, length 148
20

Alright, then it is correct. I thought the dump was from router.

What machine/OS is running the WG server? If it has iptables or some sort of firewall maybe you could post here its configuration?
Otherwise I can only think of enabling debugging on WG server.

Also post here the configs from R7800, maybe there is indeed something weird there.
uci show network; uci show firewall; ip -4 addr; ip -4 ro; ip -4 ru; iptables-save -c

1 Like