Hi, so I have a little Proxmox box with two VMs: VM1 and VM2 which is a clone of VM1. I change the mac of VM2 to avoid conflict and I reset the machine ID of VM1. I then have a seperate pfSense machine machine that that acts as router, firewall and DHCP server. Proxmox is on the 192.168.20.1/24 domain. In the DHCP server, Proxmox get IP 192.168.20.8 explicitly assigned. All good to this point. I’ve set VMs on pfSense to get the 192.168.20.9X addresses assigned. VM1 gets 192.168.20.91 assigned, while VM2 should be getting 192.168.20.92.

But this is what actually happens:

  • VM1 gets 192.168.20.106 assigned, despite telling pfSense to assign it 192.168.20.91. This happens even with VM2 shutdown. The DHCP Lease table is showing 91 up and running and does not list 106. Yet, the ARP table shows 106 assigned and no 91 assigned. This is even with me deleting the 106 entry from the ARP table several times and rebooting both the VM and the Proxmox server.

  • The VM is definately getting 106 assigned as I can log into it with 106 IP but 91 doesn’t respond (no route to host).

Is this something to do with the bridge configuration on Proxmox? Iv’e added a screenshot of what I see. It doesn’t seem to be that complicated to setup a bridge?

I can’t get my head around this so tips are welcome.

EDIT: I’ve just run ‘sudo ip’ on the VM and i see the ens18 interface with the MAC I assigned to it and the 106 IP assigned to this interface. There are then seven of ‘vethXXX’ interfaces. Not sure what these are. There are also four ‘brXXXX’ interfaces, one ‘loXXXX’ interface and one ‘docker0’ interface, the latter probably used by the docker subsystem running on the VM. I imagine the ‘brXXXX’ interfaces are the docker containers themselves (I think I have four running). But what are the ‘vethXXXX’ interfaces? Sounds like its something to do with “virtual interface”. Why so many and what is creating these?

  • Appoxo@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    Doing it that way is a sure way of loosing your mind at a certain scale.
    Don’t do that.
    Ensure your DHCP and DNS work as expected and save your headache for the future when you want to expand the homelab to something like https certification or IPv6.
    Static IPs should be used sparingly. Like for servers.

    • Eggymatrix@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 day ago

      I agree with you. I am not at a scale were it matters so I don’t bother. I only have a couple dozen servers to harness for work. Point is that OP does not sound to be at that scale either

      • Appoxo@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 day ago

        My scale is ±5 servers. And of them only the ones that are critical like my AD/DHCP/DNS or my backup servers are actually static.

        I’d peobably get an aneurysm seeing your network ;), /j
        But if it’s tidy and documented, more power to you :)

        • Eggymatrix@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          5 hours ago

          Well my entire network doc is a 30ish lines .txt file that looks like this example:

          • Hostname11 10.0.0.11 master db1
          • Hostname12 10.0.0.12 db1 backup
          • Hostname13 10.0.0.13 ui back end 1
          • Hostname21 10.0.0.21 master db2
          • Hostname22 10.0.0.22 db2 backup
          • Hostname23 10.0.0.23 ui back end 2

          Then some other general stuff on some other 10.0.1.x network etc

          Once you take care assigning static blocks and it makes sense you don’t have any surprises. Db1 crashed? Lookup its config data, reinstall machine, recover from backup and nothing else needs to be configured.