So, I finally got this project (PiAlert) working how I’d like.

It basically uses arp to keep track of devices on your network, and let you know when new ones join. It gives some basic stats like uptime, etc and you can configure a few different notification options to be alerted when a rogue device connects.

Anyways, to get this work on my network involved setting up several network interfaces, as I have quite a few VLANs I’d like to keep an eye on. While everything seems to be working, I feel like I may have created an asymmetric-routing situation, as now when I SSH to the VM hosting this, it will freeze up after a few seconds.

My interfaces look like such. The problem is that I am accessing this VM (hosted on 192.168.1.0/24) from my personal network (192.168.6.0/24). My personal network has access to 192.168.1.0/24 and obviously to it’s own subnet, so I think packets are getting confused, as there are multiple routes they can take to this VM.

I believe this is confirmed, because if I disable the entry for 192.168.6.0/24 in my /etc/network/interfaces file, the problem goes away.

How should I handle this? I’ve tried some simple UFW rules to try to force things to only use the 192.168.1.0/24 interface, but to no avail.

Edit: Sorry for the weird markdown, not sure why it’s highlighting keywords

  • @[email protected]English
    1•6 months ago

    What does the routing table look like on both ends? Are you accessing it by name or IP address? If by name, what’s the record in DNS? Have you taken a packet capture to inspect the actual packets?

      • @[email protected]English
        1•6 months ago

        Disclaimer, routed networking is not my strong suit, so it’s hard to say what’s going wrong here without checking it live. How is your router configured? Does it know about all these subnets? I’d check there, and make sure the masks are set properly. Also check the arp table on your switch, if you can.

        I don’t see anything obviously wrong here… Your PC says “I want 192.168.1.10” (or whatever), and you don’t have a route for that, so it goes out the default route to 192.168.6.1. The router should see the destination, and send it out the proper interface to reach 192.168.1.10. The server should receive it on that interface, and… hmm. It knows the reply should go to 192.168.6.10, and it has a route for that, though it is to 192.168.1.1… are these physical or virtual interfaces? If they’re physical that might be your problem. If they’re virtual, the reply should go back out to the switch and router via the same physical interface, and the router should happily route it back to you.

        I’d take a packet capture on the router too just to see what it sees. Maybe a diagram would help regarding physical vs. virtual interfaces. I’m assuming you don’t actually have six Ethernet cables between your server and switch, but I’ve seen weird shit before.

        • @rootOP
          1•6 months ago

          Thank you for the great reply! I have looked through my firewall rules, and I can’t seem to find anything that seems out of the ordinary. Interestingly enough, if I ssh to the VM via 192.168.6.X from my PC which is also on 192.168.6.X there are no issues. It’s only when I try to SSH into the 192.168.1.X interface on the VM that I experience the disconnection issues.

          I’ve added some ufw rules to only allow incoming from 192.168.6.X to 192.168.1.X on port 80 and 443 (to see the web GUI) and deny from most of RFC1918 to it otherwise

          To                         Action      From
--                         ------      ----
192.168.1.40 80            ALLOW       192.168.6.0/24            
192.168.1.40 443           ALLOW       192.168.6.0/24            
192.168.6.40 22            ALLOW       192.168.6.0/24            
192.168.1.40               DENY        192.168.0.0/16

          I’m hoping that there’s no asymmetric routing happening as a result of this VM and it’s interfaces (these are virtual interfaces that I created in Proxmox and then configured in the VM via /etc/network/interfaces