Cannot get WireGuard working without WAN

Except there IS traffic to 192.168.1.148 . I can ping google.com for example.

When I use the tunnel, I can ping 192.168.1.148 from the phone. No traffic to any other members of the same subnet.

That route is probably useless. The archer is not acting as a router but as a switch.

192.168.1.0/24 is not specified anywhere.

How am I providing sparse information? I provided the full /etc/config[network/config]

The archer is a DHCP client, yes. It gets an IP of 192.168.1.148, subnet mask of 255.255.255.0, and gateway of 192.168.1.1.

  • Wow...correct...unless you're running Wireguard on it :wink:

???

Pause...

You're not giving enough details...

Obviously...you're trying to take packets from X, encrypt them - and send them to network Y.

  • TP link is assumed to get IPs from "Google WiFi" or "modem"
  • "Google WiFi" or "modem" does not equal 192.168.1.0/24
  • Traffic from X is using your OpenWrt running Wireguard as its gateway (router)

If any of those assumptions are wrong, please clarify.

Then:

  • Where is Y (192.168.1.0/24)?
  • And is this a virtual WG network; or a real one (i.e. PHY, NAT, VLAN, etc. on another device running WG)?

...

PC > SSH > Archer > ping google.com or anything > works
Phone > WireGuard > ping 192.168.1.148 > works
Phone > WireGuard > ping anything else > does not work

The Google WiFI is the DHCP server, not the TP-LINK. The Google WiFi's network is 192.168.1.x . 192.168.2.x is WireGuard's network as it's a layer 3 VPN.

Using "Street Logic" to approach this...

Yes you're using your LAN DNS and Gateway.

Phone is:

config wireguard_wg0
        option public_key 'x'
        option description 'x'
        list allowed_ips '192.168.2.0/24'

:question:

SO...there is no 192.168.1.0/24. Solved!

  • So who is 148...guessing the phone?
  • But who is 192.168.1.1, and where is it's peer config and key?
  • You never actually say who 192.168.1.1 is either... (I only assumed the phone, but then you said you pinged it...)
  • None of these hosts on 192.168.1.0/24 have their own individual key and config!

:confused:

And where is 192.168.1.0/24!?!?

You do know you must make a key for each host, correct?

192.168.1.1 is the Google WiFi
192.168.1.148 is the Archer - WireGuard config shown above
192.168.2.2 is the phone - WireGuard config shown above
192.168.1.0/24 is not specified anywhere. Ctrl+F on this thread shows only posts by you and me responding to them.

I feel like I already know the answer and am wasting everyone's time.

All of your config is wrong then, start over.

I asked you to correct me above. :-1:

OMG...my brain hurts, I think you are route looping thru an encryption connection...on the same LAN!

This is a joke, rite? (I won't say troll)

You failed to mentioned you're testing this in LAN...and hid it too.

Lastly, is there any other device running Wireguard (except the phone, or a router running NAT), and if not, why do you pass traffic thru its interface?

@neheb,

https://www.wireguard.com/#cryptokey-routing

Also, this also calls into question if any X traffic is actually using the TP-Link as its gateway.

I would strongly recommend that you reset your Archer (OpenWrt) to defaults and start over. There is really very little that you need to do -- keep it simple. No extra routes, etc.

if you want to use the dumb AP type configuration, it should work. Just change the LAN to DHCP client instead of a static IP (just as you had done previously). Install WG. Configure the WG interface with the keys and then do the remote peer. That's it. Don't add any static routes -- they will only mess things up.

This is what your Archer config should look like:

config interface 'wg0'
        option proto 'wireguard'
        option private_key '<INSERT_PRIVATE_KEY_FOR_ARCHER>'
        option listen_port '51820'
        list addresses '192.168.2.1/24'

config wireguard_wg0
        option public_key '<INSERT_PUBLIC_KEY_FROM_PHONE>'
        option description 'Phone'
        list allowed_ips '192.168.2.2/32'
        option route_allowed_ips '1'
        option persistent_keepalive '25'

On your phone, the setup should generally be the following (you'll have to create a syntactically correct config file or enter things into the correct fields

Wireguard Local Interface (on phone)
Private_key = <INSERT_PRIVATE_KEY_FOR_PHONE>
Addresses = 192.168.2.2/32
DNS_server = 192.168.1.1

Peer Config (on phone, refers to Archer):
Public_key = <INSERT_PUBLIC_KEY_FROM_ARCHER>
Endpoint = <INSERT_PUBLIC_IP_ADDRESS> # For testing, could use LAN address of Acher 192.168.1.148
Allowed_IPs = 0.0.0.0/0 # If you want to pass all traffic through the tunnel; if just looking for LAN access, use 192.168.1.0/24
Persistent_keepalive = 25 

That's all you have to do! Do not overcomplicate the configuration.

EDIT: Forgot to include the firewall additions (you already had these mostly correct):

config zone
        option name 'WireGuard'
        option network 'WireGuard wg0'
        option input 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'
        option output 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'WireGuard'
1 Like

I have basically the same setup on my router (different network) and it works perfectly fine.

For the benefit of other users reading this thread in the future, the OP appears to be over complicating the configuration by using ProxyARP (which and amounts to a hack in this context). I would recommend against this method, and the OP has also not shared enough info (And has presented details in the most confusing ways possible) such that it would be very difficult for any other user to actually make a functioning wg installation. Other threads will almost certainly be more helpful for the vast majority of users.

1 Like

It should work as long as those devices use the TP-Link as its gateway.

This is where Wireguard exists, hence it's a router (if I understood correctly).

That usually means it's not a dumb AP config - meaning that the TP-Link is issued as the gateway address (either statically or via DHCP).

Lastly, the OP never identified any real far end for encrypted traffic either. Remember this setup was just a loop thru LAN.

EDIT: I just want to note, routing rules on the phone likely won't allow you to connect to WiFi in 192.168.1.0/24, then connect via Wireguard to 192.168.2.0/24; and route thru WG back to 192.168.1.0/24. The phone is smart enough to know that network is local. And I was gong to tell @neheb that you may not want to use 192.168.1.0/24 if you VPN into your LAN. If you are again at a location that uses that subnet, the same route problem would occur on your phone; and your traffic would leak into the insecure network you connected to.

1 Like

Yes, this is my assumption, too. I ran a quick test on a spare (dev) router I have lying around, and setting the LAN IP to DHCP client mode does indeed pickup the DNS and gateway information from the upstream DHCP server (I did an opkg update and it worked perfectly). Obviously if the IP is manually assigned, the gateway/DNS must also be specified.

FWIW, when I was referring to the "dumb ap" configuration, I was really referring to the LAN-LAN connection between the two routers, DHCP (server) disabled on the secondary router, and not using the WAN/NAT+firewall. @lleachii - you are probably technically correct in that the moment you enable anything with routing, it ceases to be the dumb AP config, but I was generally thinking in terms of the two routers both having their LANs defined in the same network.

I have the same assumption. In fact, WireGuard makes the routing really easy :slight_smile: -- much more straight forward than other L3 VPNs.

I had the impression that the OP was trying to use the WG VPN as a remote access method to their LAN (and/or "road-warrior"-to-"home internet" to avoid geo-restrictions and such). But because the OP refused to properly explain the specific goals, issues (and requested test results), and config information, I may very well be mistaken about this.

1 Like

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