Successful WireGuard tunnel works, but not one way when computer uses 2nd IP
I've been battling a VPN connection for a week now. Tried to get some help from this reddit thread.
I have a WireGuard tunnel that can work both ways with DHCP or Static IPs on the same subnet. But I'm trying to access a device on the other end using a computer and I set the other subnet as a secondary IP, then I add a routing table to the that subnet.
Seems to work in one direction, but the other side doesn't see my computer that on a different subnet even though I've added routing on the computer and an IP in its own range. I think maybe it's because the gateway on the computer is set to the 192.168.1.1 range, not the .3.1.
How can I get the one side working that's having the problem? I have both Allowed IPs as 0.0.0.0/0.
(existing LAN 192.168.1.0) -- 192.168.3.1 -- (10.1.1.1===tunnel===10.1.1.2) -- 192.168.2.1
All I need is one computer on the 192.168.1.0 side to have a two way communication with one device on the other side.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
OP in the reddit is you, but you posted on this forum is of a different topic now?
first reaction would be routing issues.
so my question is where is this 3.1/24 device?
or add the new 3.1/24 in this map.
the problem is no longer the wireguard. if you have set 0.0.0.0, then it should forward all.
question is 3.1 is not routed properly somewhere in this setup. you should show the routing tables.
you should route
or same DST but next hop is the computer's LAN IP because 3.1 is created on that computer. no one else in the network knows where it comes from. so maybe the PC should route 3.1/24? my guess
- Copy Link
- Report Inappropriate Content
Hi @MrTom
Thanks for posting in our business forum.
Can you give a picture of the issue to illustrate it?
Do you mean the Client shows nothing connected to the network?
- Copy Link
- Report Inappropriate Content
@Tedd404 The new map just has 1.50 changed to 3.1. The 3.1 is the LAN of the ER605 at Site A. So the ER605 WAN is 0.10 and the LAN is 3.1.
The computer on my main Site A LAN is 192.168.1.218 (192.168.1.1 GW), but I do have a secondary static IP set of 192.168.3.200. I added a routing in the PC: Dest=192.168.2.0 GW=192.168.3.1.
I can ping anything on the 2.0 side and it responds, even access a network share on the 2.100 laptop. But from 2.0 side I can ping my 3.200 computer one way, the 3.200 received the ping, but never responds.
If I take the 3.1 ER605 LAN out of my main network, enable DHCP on it, and connect a laptop to it, it works. I can ping 2.0 side, and 2.0 side can ping the laptop. I thought maybe adding a DHCP Address Reservation would do the trick, but didn't seem like it did.
It's just that a PC with a seconday IP in 3.0 does not work, as well as a PC with a static subnet on 3.0/24, but actually it did work on another windows 7 PC when I set it to a static IP subnet of 3.0/24. It does seem like a routing issue, but I just can't figure out where the missing route is. I've tried a lot of different combinations and my brain is spinning.
EDIT: Wireshark on Site A PC 3.200 shows a ping packet coming in from 10.1.1.2 (which is Site B's WireGuard Local IP Address), and the destination is 192.168.3.200. But it does show a message (no response found!) I also just did another static IP test on main LAN of subnet 3.0 on my desktop and it didn't respond to a ping from the 2.0 side, I thought it did before. Maybe the static IP in subnet 3.0/24 is a Windows 11 thing, it worked on a Windows 7 PC. Both PC's firewalls are turned off.
EDIT2: Do you think it would work better if I had the tunnel LAN sides (2.0/24 3.0/24) on the same subnet? ie. 172.16.0.0/16? (nevermind, overlapping networks)
Ping from Site B to Site A (captured at Site A)
Ping from Site A to Site B (captured at Site B)
tracert on Site B to Site A
tracert on Site A to Site B
Computer's routing table (the one with the secondary IP 3.200)
- Copy Link
- Report Inappropriate Content
@Tedd404 Ok, I got pings to go through to Site A while using a secondary IP at Site A. It was a combination of my firewall was still enabled on this PC I was using, I had disabled it on another. And also I had to add a static route DST=10.1.1.2 GW=192.168.3.1.
Apparently while you're plugged directly into the LAN port of the ER605, and device knows how to contact the WG tunnel IP, my cases 10.1.1.1 and 10.1.1.2. But an external device just using the same subnet did not know how to route the 10.1.1.2 traffic. Since IPs coming into each device on each end has the tunnel IP, and not really the device on the other end's IP. I hope this doesn't cause a problem with the timeclock trying to use the tunnel IP instead of the PC's IP.
So along with a secondary IP and GW, I added a static route for DST 2.0 and 10.1.1.2 to 3.1. Turned off the firewall, and now it works both ways. I'm able to access a network share on Site A from Site B plus ping the PC.
I think this is solved for now, but I'll wait a while longer until I can permanetely implement this solution. Thanks for the help.
EDIT: Unfortunately the time clock link doesn't work. Everything else does through it. I think the Pyramid time clock software or the time clock itself does not like the 10.1.1.1 tunnel IP that comes out on the other end. Would be nice if WireGuard could forward packets exactly as they are, like a transparent tunnel. I may just have to make an insecure L2TP tunnel for this to work.
- Copy Link
- Report Inappropriate Content
in response to your last edit.
MrTom wrote
EDIT: Unfortunately the time clock link doesn't work. Everything else does through it. I think the Pyramid time clock software or the time clock itself does not like the 10.1.1.1 tunnel IP that comes out on the other end. Would be nice if WireGuard could forward packets exactly as they are, like a transparent tunnel. I may just have to make an insecure L2TP tunnel for this to work.
you should redirect all traffic to the router as it is the device which knows where to route.
on your devices, it is not capable of that. as the router is the one who knows WG interfaces.
so the basic idea is to set the routing tables to the gateway first.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 703
Replies: 5
Voters 0
No one has voted for it yet.