0

There are two devices connected to the same LAN network:

A with IP 192.168.1.1,
B with IP 192.168.1.0.

I connected B through VPN (WireGuard if that matters) exposed externally (B on server - BS - obtained address 10.8.0.3) and decided to route all the traffic through the tunnel by putting 0.0.0.0/0 into settings. This resulted in creating internal (for B) rule that what is sent to 0.0.0.0/0 goes to BS.

Next step is ping device B from device A - it succeeds.

What I would think is that ICMP packet had been transferred through the tunnel of B and came back. But then how would it be possible when address of B is of class C, while server sits on A class network having none of C interfaces? It won't even loopback to BS because its address on server is 10.8.0.3 (not 192.168.1.0).

Another thing is above could happen but with the caveat that B reassembled the packet with BS IP. However there was no time difference getting the response back. It looked like another (LAN) interface handled the request.

And the last thing is special treatment applied to ping. ICMP belongs to L3 as well as VPNs. There must be a frame coming from particular IP to another IP. In layman's terms it should apply the same behavior as normal traffic, but it doesn't.

Help me connect the dots. Any articles are also appreciated.

EDIT:
As IPs differ a bit from the question (to keep things simple), I adjusted them accordingly.

My route table:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.1.0     35
          0.0.0.0          0.0.0.0         On-link          10.8.0.3      0
         10.8.0.3  255.255.255.255         On-link          10.8.0.3    256
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.240.0         On-link       192.168.1.0    291
      192.168.1.0  255.255.255.255         On-link       192.168.1.0    291
   192.168.15.255  255.255.255.255         On-link       192.168.1.0    291
     192.168.48.0    255.255.240.0         On-link      192.168.48.1    271
     192.168.48.1  255.255.255.255         On-link      192.168.48.1    271
   192.168.63.255  255.255.255.255         On-link      192.168.48.1    271
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       192.168.1.0    291
        224.0.0.0        240.0.0.0         On-link      192.168.48.1    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       192.168.1.0    291
  255.255.255.255  255.255.255.255         On-link      192.168.48.1    271
===========================================================================
Persistent Routes:
  None
Improve this question
8
  • show us your route table. route print (windows) or route (linux). add it to your question. in all likelihood, you have a more specific route to 192.168.0.0/24.
    – Frank Thomas
    Commented Jan 21, 2023 at 0:02
  • 1
    you have 2 devices on the same IPv4 network on the same (physical?) LAN - of course they can ping each other directly. the VPN is irrelevant
    – Jaromanda X
    Commented Jan 21, 2023 at 0:53
  • @JaromandaX, some VPN clients (though not usually WG clients AFAICT) will remove all local routes from the route table and force use of the default gateway (which is directed into the tunnel). most of those clients support a feature called "split tunneling" . you are probably quite right though from what experience I have with WG. There are lots of usecases where its helpful to completely isolate a system from the LAN its directly connecting to however (like coffee shops), so its not an uncommon behavior.
    – Frank Thomas
    Commented Jan 21, 2023 at 1:36
  • @FrankThomas - I hadn't thought of that
    – Jaromanda X
    Commented Jan 21, 2023 at 1:46
  • On at least Linux, wg-quick is made to "override" (effectively-speaking; by the means of ip rule and an alternate route table) the default route only. Any route on main table that has prefix length larger than 0 would remain in effect.
    – Tom Yan
    Commented Jan 21, 2023 at 2:34

1 Answer 1

Reset to default
1

This is fairly standard VPN behaviour - the packet is not going out the VPN at all.

What VPNs typically do is add a default gateway/route of last resort/catch all route to your routing table - however because the devices are in the same subnet there is a specific route for them - and more specific routes are preferred over less specific ones (and indeed if this was not the case, how would the computer find the router to route the vpn traffic through?)

Improve this answer
2
  • That's what bothered me too. Isn't the rule with lower metric preffered, making other automatically hidden?
    – Jon
    Commented Jan 21, 2023 at 11:53
  • Metrics pick pick between routes of the same length but more precise routrs (ie smaller subnets) are evaluated first. So if you have 2 default gateways the one with tje lower metric will be pteferred, but a /24 will be prefetred over a /23 or wider even if the /23 has a lower metric.
    – davidgo
    Commented Jan 21, 2023 at 17:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .