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

  • Creat@discuss.tchncs.de
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    Yes I know why you have so the interfaces, but as far as I know: Linux simply can’t do what you want. So if you want to access PiAlert from your main PC on .6.X, you need to make that accessible from .6.Y on that VM. If you want to have the management port (UI) only open on the management interface, you would need to remove it’s interface on .6.X.

    As I said, as far as I’m aware Linux simply can’t not route packets properly in an environment like that. I won’t respect that the interface packets came in on needs to also be the outgoing interface for the return trip. I also had that problem and eventually j I’ve just given up.