IP picky devices on my lan not working with WireGuard

Hi
This problem is a different topic than getting WireGuard to work. Now that my WireGuard is working here is the problem.

I still have 4 devices that won’t WG communicate. They are funnily designed in that they won’t respond unless the ip addr communicating with them is on the their same subnet, 192.168.1.???.
If I hit a DOS box and enter device address + commands (direct command of device mode) the devices do not see 192.168.1.xxx ip address over wireguard. So they don’t/won’t respond. I set wireguard up with 10.0.1.2/24 as WG interface address range on my laptop and 10.0.1.1/24 on Omnia end. The devices see as my IP address (10.0.1.2).
How can I set WG up to have these devices see 192.168.1.??? So they are satisfied I am on the same subnet and will communicate with me. No amount of rudderless playing around has solved the problem so I need expert help .
For my benefit which end of WG should set up the IP address the devices receive?
Is it the Omnia end or the laptop end?
I see 10.0.1.2 as login on other devices that can report this, which leads me to believe the laptop sets up the IP address. If I change laptop to 192.168.1.252/30 WG interface range (/30 to stop address conflicts below this range) then devices see 10.0.1.1 which is Omnia WG interface addres range. If I change Omnia to 192.168.1.253/30 WG interface range), traffic thru tunnel stops. If I put laptop back to 10.0.1.2, then comms start again but 10.0.1.2 is login IP address again. (Which probably is normal WG behavior for ALL the MUNGING and SPINDLING/folding I am doing. Just trying anything/every thing)
How can I get IP Picky devices to see my login as 192.168.1.??? (on their subnet) through WG

Does any one have any thoughts on this??? This is the last hurtle I have and these 4 dev are the most important devices on the network next to having remote LUCI/FORUS access which I now have.

Thanks in advance
Idaho Kid

Can you somehow influence their routing table to fix them?

You also need to have routing and ACLs set correctly. Make sure that your notebook knows that it should access 192.168.1.x via 10.0.1.1 and that Wireguard wouldn’t filter those adresses.

I’ve seen broken devices that would open up to local network only as well, the solution depends on what services are running there. If it is something as simple as web interface, you can sidestep the problem by setting port forwarding on Omnia and use port on Omnia via WG which Omnia will use to connect over local network to the device. Other possibility is to setpu complete NAT on Omnia from Wireguard network to your LAN network.

In Wireguard all devices are equal and you setup IP address on each device separately. But you also set ACL specifying which peers are connected and what IP ranges can come from those. And all IP ranges you have follow classic routing rules as well, so in IPv4 world, you have to try hard to avoid conflicting ranges.

2 Likes

Welllllllllllllllllll I’m back, after a very long night and day and that night digesting all the hints try’s and suggestions. Thanks loads for all the responses I really appreciate it. I was not expecting that much Miska.
This topic now has taken an abrupt turn an got dumped on it’s head.

I looked at your suggestion on routing tables and I really could not find any real presents in the tables for the devices because of what they are. I not the best person on firewalls and routing tables they are still very mysterious black boxes to me. As far as setting up anything special in routing tables and firewall is something I am still in the very early stages of learning. As far as ACL’s that is a dirty work in my world. I got my Bu-- kicked right up around my ears with ACL’s when I got this laptop. It was “used” and set up to the max with ACL’s. I could not do ANYTHING on it. I got help and this setup had him scratching his head. We tried lots of stuff and nothing worked and per his suggestion a re-image followed. NO ACL’s now
ACL’s = 7 Me= 0. This armchair Quarterback was sacked so many times I still hurt.
With ACL’s as the very last solution I want to try, I looked at WG interface IP’s again.

The devices I don’t really feel are broken it’s just the way they work. They have to be accessed with app’s and I feel it’s more the app’s than devices. I do have a STATIC IP address reserved and set up for each of the devices. but no port forwarding. They don’t have ports. If they do have ports it’s not documented and they are not available for me to use.
Its all about the app’s, I can PING the devices but that’s all I can do with direct addressing. (More about PING later.)
Started trying WG interface IP experimenting again and long story short I stumbled upon the correct notation on Laptop, when once I forgot to specify subnet range and WG wizard filled in what it wanted to and I was tired and left it, (Fix it later) and the WG pick made things work.

I now have 192.168.1.1 as my logging in IP address for devices on the Omnia network.
yessssssssssssssssssssssssssss!!!
But (there is always a BUT with me), short lived enthusiasm, the devices still don’t work and are not happy. The app’s still can’t access them!!

Now here’s where the topic turns into left the field and ends up on it’s head. There is NO excuse now 192.168.1.1 is definitely in the right subgroup but still dead. After trying unsuccessfully to WireShark the data flow and being very tired, I ping’ed one and got no response. WHAT??? They have always pinged before. None of them pinged.
closed the tunnel and direct connected and PING is back. Back to WG and No pings.
This very shortly resulted in me trying to ping everything on my router. Under WG I get 3 devices that will ping. Every thing else ping DEAD. Deactivate WG and I get 20 devices that will ping. What ??? is going on with WG. What have I missed. Do I understand WG and what it is doing? What protocols are lost under WG, that are there in direct connect?
I am not sure where to look now. The devices that won’t ping under WG are working under WG . The do their job, I can log into to them, they respond normally to commands. Just no pings.
Just how transparent is the WG tunnel to data and protocols? (NOTE: Devices that WILL ping under WG are very old devices, but still goodies). Why would WG stop Pings?
Is what is stopping pings also stopping the 4 devices from working?
Where do I look? (SO MANY QUESTIONS NOW)

Thanks in advance
Idaho KId

Could you draw a simple plan of the desired network topology, with IP addressing scheme of all sides of the network?

Sometimes, a picture is worth a thousand words…

2 Likes

IMG_0536-smallest
Hi Hagrid

Thanks for responding

Above is a very simple hand drawn diagram of what I am doing.
The Goal = Having the very same user experience under WG VPN as I do when I am up here at the remote site direct connected to OMNIA port 4.
Having everything be accessible and work as intended under WG the same, as if am here and direct connected. I am almost 85% there. Just one device with 4 ports away from perfection. ALL! OTHER DEVICES WORK UNDER WG.

Hope you can read it. UPLOAD forced me to use the smallest file size I had and that affects resolution.

It’s all very simple. I have nothing fancy going on and as I noted on the diagram a lot of my (close to router) connections are direct Ethernet and some are WIFI. (about 50, 50)
ALL devices are static addressing. IP 's are all in 192.168.1.x range. IP range 1-99 are out of DHCP control. Kept some addresses open for just what ever. DHCP starts at 100 and expands 50 more. (x.x.x.150 highest DHCP address)
EVERYTHING is reserved address based on Mac. Some devices would not let me decide what static IP I wanted, so I used addresses reservation to force DHCP to assign the QUASI static addresses I wanted.
Laptop WG interface address is 192.168.1.254/32. (Note: WG chose notation. Refer to last post for details) Omnia WG interface address is 192.168.1.253/30.( I chose this notation.) Allowed Address thru tunnel 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1 for laptop (WG GUI interface chooses this.) Allowed addresses for Omnia thru tunnel are 192.168.1.1/24.
As I stated in last post when I entered WG interface IP address for Laptop WG chose the notation because I forgot to and it chose /32, I had been putting in /30 and it would kill comm’s thru tunnel. Tunnel stayed up but nothing went thru it. When /32 was chosen by WG it worked. I am now 192.168.1.1 IP user on Laptop and that should have made things work on Problem-Child. (See last post for description/details (To many???) on Problem Child).
I don’t believe I have cut off subnet to Problem Child because I have a few higher IP addresses than the range of problem device and they work just fine under WG and it’s tunnel. So to recap, I have many IP addresses below problem device and several IP device addresses above problem device that do work under WG.

As I stated in last post I CAN’T Ping any device hooked to router with WG active, (with the exception of 2 real old devices.) With WG inactive and direct connected to router I can PING EVERYTHING. I have a gut feel that what ever is causing the PING problem while WG active, is what is affecting the problem devices. With 192.168.1.1 as my user IP the problem devices and apps should work. So back to my last post main question is what is WG doing to the data stream to affect a PING request? I might could use that info to get WireShark to help me in fixing the problem. Having WG kill all PING traffic is (to me) significant. Has Ping protocol changed in last 8 - 9 years? Devices that can still be PINGED with WG active, are at least that old of not older.
I hope I have given enough info, if not ask for more specific. I am leaving remote site today (09-16-21) and I don’t know when next trip up date will be. I can WG in and try some stuff but anything that might break WG I would hesitate doing. Can’t fix if not here
and having WG working for Remote Luci and Fortise is to important.
Would appreciate any thoughts/actions you can come up with.
Thanks in advance

IdahoKid

Hi @IDKID! To be honest, I still don’t understand your problem.

Post here the relevant sections of network configuration (the content of /etc/config/network with redacted wg keys) and the routing table of the laptop while connected to the VPN.
Also the traceroute information would be useful.

Please see Network Troubleshooting | How to Fix a Network Connection | Computer Network | CompTIA for detailed information about network troubleshooting tools.

Hi Team

I finally have some time to get back to this.

My problem is simple. I can’t get devices 192.168.1. " 121 and 122 and 123 and 124" to work over WG VPN. They should work. No obvious reason they not working, now that I am showing up on the OMNIA with the same subnet they are on.
Simply, they should be working. EVERYTHING else I have hanging of my OMNIA works over WG VPN! Everything else!

I really really want to use these devices remotely and something is stopping me. I just can’t see it. If I am up at the remote site and plugged in on Ethernet or WIFI’ing it they work. What is WG VPN doing to, or lacking in, or changing what part of the environment to kill them, on OMNIA or Laptop or both at same time, is the question?
I just want to get them them fixed & working on VPN.

Here is your requested info below, hope I did it right.

8888888888888888888888888888888888888888888888888888888888888888888
root@turris:/etc/config# cat network

config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’

config globals ‘globals’
option ula_prefix ‘fd7c:de15:260e::/48’

config interface ‘lan’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘192.168.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option bridge_empty ‘1’
option ifname ‘lan0 lan1 lan2 lan3 lan4’

config interface ‘wan’
option ifname ‘eth2’
option proto ‘dhcp’
option ipv6 ‘0’

config interface ‘guest_turris’
option enabled ‘1’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘10.111.222.1’
option netmask ‘255.255.255.0’
option bridge_empty ‘1’

config interface ‘wan6’
option ifname ‘@wan
option proto ‘none’

config interface ‘wg0’
option proto ‘wireguard’
option private_key ‘REDACTED’
option listen_port ‘51820’
list addresses ‘10.0.0.1/24’
list addresses ‘10.111.222.1/24’

config interface ‘wg1’
option proto ‘wireguard’
option listen_port ‘51821’
option private_key ‘REDACTED’
list addresses ‘192.168.1.253/30’

config wireguard_wg0
option public_key ‘REDACTED’
option description ‘Phone’
option preshared_key ‘REDACTED’
option route_allowed_ips ‘1’
option persistent_keepalive ‘25’
list allowed_ips ‘10.0.0.2’
list allowed_ips ‘192.168.1.1/24’
list allowed_ips ‘10.111.222.1/24’

config wireguard_wg1
option public_key ‘REDACTED’
option description ‘Laptop’
option preshared_key ‘REDACTED’
option route_allowed_ips ‘1’
option persistent_keepalive ‘25’
option endpoint_port ‘51821’
list allowed_ips ‘192.168.1.1/24’
list allowed_ips ‘10.111.222.1/24’
88888888888888888888888888888888888888888888888888888888888888888888
laptop routing table
111111111111111111111111111111111111111111111111111111111111111111111111111111
C:>netstat -r -a

Interface List
19…WireGuard Tunnel #2
12…c4 46 19 6f 91 bb …Broadcom 802.11n Network Adapter
11…a4 ba db d8 34 21 …Realtek PCIe GBE Family Controller
1…Software Loopback Interface 1
18…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
20…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
222222222222222222222222222222222222222222222222222222

IPv4 Route Table
333333333333333333333333333333333333333333333333333333
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.20.10.1 172.20.10.2 25
0.0.0.0 128.0.0.0 On-link 192.168.1.254 5
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 192.168.1.254 261
128.0.0.0 128.0.0.0 On-link 192.168.1.254 5
172.20.10.0 255.255.255.240 On-link 172.20.10.2 281
172.20.10.2 255.255.255.255 On-link 172.20.10.2 281
172.20.10.15 255.255.255.255 On-link 172.20.10.2 281
192.168.1.254 255.255.255.255 On-link 192.168.1.254 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.20.10.2 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.20.10.2 281
44444444444444444444444444444444444444444444444444444444444444444
Persistent Routes:
None

IPv6 Route Table
55555555555555555555555555555555555555555555555555555555555555555
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
1 306 ff00::/8 On-link
66666666666666666666666666666666666666666666666666666666666666666
Persistent Routes:
None

77777777777777777777777777777777777777777777777777777777777777777
tracert
C:>tracert -h 5 192.168.1.121

Tracing route to 192.168.1.121 over a maximum of 5 hops

1 103 ms 82 ms 79 ms 192.168.1.253
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.

Trace complete.

C:>tracert -h 5 192.168.1.124

Tracing route to 192.168.1.124 over a maximum of 5 hops

1 90 ms 131 ms 120 ms 192.168.1.253
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.

Trace complete.

C:>tracert -h 5 192.168.1.120

Tracing route to 192.168.1.120 over a maximum of 5 hops

1 147 ms 114 ms 111 ms 192.168.1.253
2 * * * Request timed out.
3 135 ms 120 ms 118 ms 192.168.1.120

Trace complete.
88888888888888888888 End of your requested info 888888888888888888888

88888888 Add on info that I am including. Disregard if not useful 888888888888
C:>ping 192.168.1.121

Pinging 192.168.1.121 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.121:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>ping 192.168.1.124

Pinging 192.168.1.124 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.124:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:>
C:>ping 192.168.1.120

Pinging 192.168.1.120 with 32 bytes of data:
Reply from 192.168.1.120: bytes=32 time=117ms TTL=12
Reply from 192.168.1.120: bytes=32 time=108ms TTL=12
Reply from 192.168.1.120: bytes=32 time=143ms TTL=12
Reply from 192.168.1.120: bytes=32 time=91ms TTL=126

Ping statistics for 192.168.1.120:
Packets: Sent = 4, Received = 4, Lost = 0 (0% lo
Approximate round trip times in milli-seconds:
Minimum = 91ms, Maximum = 143ms, Average = 114ms

(I can Ping Every device on my OMNIA if direct connected???)

8888888888888888888888888888888888888888888888888888888888888888888
(SOME LAPTOP PORT INFO THAT MIGHT BE USEFUL.)

C:>NETSTAT -a -b

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 Laptop3-PC:0 LISTENING
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:554 Laptop3-PC:0 LISTENING
[wmpnetwk.exe]
TCP 0.0.0.0:1025 Laptop3-PC:0 LISTENING
[wininit.exe]
TCP 0.0.0.0:1026 Laptop3-PC:0 LISTENING
eventlog
[svchost.exe]
TCP 0.0.0.0:1027 Laptop3-PC:0 LISTENING
Schedule
[svchost.exe]
TCP 0.0.0.0:1028 Laptop3-PC:0 LISTENING
[hdhomerun_record.exe]
TCP 0.0.0.0:1029 Laptop3-PC:0 LISTENING
[lsass.exe]
TCP 0.0.0.0:1030 Laptop3-PC:0 LISTENING
[services.exe]
TCP 0.0.0.0:2869 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:10243 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP 172.20.10.2:139 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP 192.168.1.254:139 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP 192.168.1.254:7439 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP 192.168.1.254:7783 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP 192.168.1.254:22059 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP 192.168.1.254:23231 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP 192.168.1.254:33328 li927-71:8003 ESTABLISHED
[hdhomerun_record.exe]
TCP 192.168.1.254:36789 192.168.1.1:ssh ESTABLISHED
[putty.exe]
TCP 192.168.1.254:47597 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP 192.168.1.254:61548 192.168.1.1:http CLOSE_WAIT
[msedge.exe]
TCP [::]:135 Laptop3-PC:0 LISTENING
RpcSs
[svchost.exe]
TCP [::]:445 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP [::]:554 Laptop3-PC:0 LISTENING
[wmpnetwk.exe]
TCP [::]:1025 Laptop3-PC:0 LISTENING
[wininit.exe]
TCP [::]:1026 Laptop3-PC:0 LISTENING
eventlog
[svchost.exe]
TCP [::]:1027 Laptop3-PC:0 LISTENING
Schedule
[svchost.exe]
TCP [::]:1029 Laptop3-PC:0 LISTENING
[lsass.exe]
TCP [::]:1030 Laptop3-PC:0 LISTENING
[services.exe]
TCP [::]:2869 Laptop3-PC:0 LISTENING
Can not obtain ownership information
TCP [::]:10243 Laptop3-PC:0 LISTENING
Can not obtain ownership information
UDP 0.0.0.0:500 :
IKEEXT
[svchost.exe]
UDP 0.0.0.0:4500 :
IKEEXT
[svchost.exe]
UDP 0.0.0.0:5004 :
[wmpnetwk.exe]
UDP 0.0.0.0:5005 :
[wmpnetwk.exe]
UDP 0.0.0.0:5353 :
[msedge.exe]
UDP 0.0.0.0:5353 :
[msedge.exe]
UDP 0.0.0.0:5355 :
Dnscache
[svchost.exe]
UDP 0.0.0.0:49154 :
[hdhomerun_record.exe]
UDP 0.0.0.0:52205 :
[wireguard.exe]
UDP 0.0.0.0:65001 :<<<<< SIGNIFICANT PORT. 4 DEVICES NOT WORKING LISTEN ON 65001 TO BE DISCOVERED.
[hdhomerun_record.exe]
UDP 127.0.0.1:1900 :
SSDPSRV
[svchost.exe]
UDP 127.0.0.1:60991 :
SSDPSRV
[svchost.exe]
UDP 172.20.10.2:137 :
Can not obtain ownership information
UDP 172.20.10.2:138 :
Can not obtain ownership information
UDP 172.20.10.2:1900 :
SSDPSRV
[svchost.exe]
UDP 172.20.10.2:49154 :
[hdhomerun_record.exe]
UDP 172.20.10.2:60990 :
SSDPSRV
[svchost.exe]
UDP 192.168.1.254:137 :
Can not obtain ownership information
UDP 192.168.1.254:138 :
Can not obtain ownership information
UDP 192.168.1.254:1900 :
SSDPSRV
[svchost.exe]
UDP 192.168.1.254:60989 :
SSDPSRV
[svchost.exe]
UDP [::]:500 :
IKEEXT
[svchost.exe]
UDP [::]:4500 :
IKEEXT
[svchost.exe]
UDP [::]:5004 :
[wmpnetwk.exe]
UDP [::]:5005 :
[wmpnetwk.exe]
UDP [::]:5355 :
Dnscache
[svchost.exe]
UDP [::]:52205 :
[wireguard.exe]
UDP [::1]:1900 :
SSDPSRV
[svchost.exe]
UDP [::1]:60988 :
SSDPSRV
[svchost.exe]
888888888888888888888 End of my add on info 88888888888888888888888888

Thanks team

I see. I would suggest you to remove the IP address 10.111.222.1/24 from the wg0 interface as it overlaps with the guest network. Keep 10.0.0.1/24 only. This defines the address of the tunnel interface.

From interface wg1 remove the IP address 192.168.1.253/30 as it overlaps with the LAN configuration; set something like 10.10.10.1/30.

The configuration of wireguard_wg0 is wrong. You need to set the allowed_ips to networks that are on the remote side of the tunnel. The same applies to wireguard_wg1. If there is only one cliennt on the remote side of the tunnel (cell phone client as example), set the allowed_ips to address of the remote side of the tunnel.

Let’s imagine you have two routers - A and B.
Router A has the LAN side 192.168.10.0/24, router B has the LAN side 10.255.23.0/24.
You need to set the allowed_ips on router A to 10.255.23.0/24 and on router B to 192.168.10.0/24.

Update your configuration according my notes and let me know if it helped or not.