[Solved] How is the guest FW blocking access to the host management?

[EricPerl]

I've been slowly migrating my network away from an EOL TP-link router to OPNsense.
Today, I made the final switch. Almost everything seems to have gone according to plan.
But I've managed to lock myself out of the proxmox host...

Configuration:
* 4-port mini-PC with new proxmox install (I suspect most is default)
* 1 port dedicated to management with an IP (10.1.1.12) in my default LAN (10.1.1.0/24)
* OPNsense VM setup with 2 PCI passthrough adapters for WAN and LAN, MGMT assigned to the proxmox bridge (10.1.1.100/32).
* I used VLANs in my primary network to isolate WAN (10.2.2.2/24) and LAN (192.168.1.1/24) from existing traffic, then slowly moved my VLANs over from legacy to OPNsense router.

As of this morning, the only devices left in the legacy LAN were: managed switches, APs, controller, proxmox host, OPNsense management and a PC. It looked like it was time for the final switch.
I updated the OPNsense LAN IP to 10.1.1.1/24 (which caused loss of connectivity).
I then just replugged cables going into my old router into OPNsense, got back into OPN and adjusted the DHCP range.
All seemed well until I tried to access the proxmox host (SSH, HTTPS) for the PC (10.1.1.10). Both fail. Ping works though...

The fact that the LAN IP range on the OPN guest is now encompassing the proxmox host MGMT interface seems to be the trigger.
I removed the MGMT interface of OPNsense (since I can now access it from LAN). No change.

I looked at FW logs in OPNsense and see the replies from proxmox RECEIVED on the LAN interface of OPNsense where they are blocked (likely because the request didn't flow there).
The proxmox management port is on the same switch as the machine I'm trying to access!!!
I used wireshark to capture mirrored traffic out of the proxmox management port.
Sure enough, the MAC in the replies from proxmox is the MAC of the LAN interface of OPNsense...
A reply from 10.1.1.12 to 10.1.1.10 (on the same switch) is being sent to 10.1.1.1 (the gateway for that network)...

I see no ARP who has 10.1.1.10 during that interaction.
After couple retries, the PC doublechecks who has 10.1.1.12 though. And then the proxmox interface checks who has 10.1.1.1... Both of these were correct all along.

I could understand some of this behavior if the proxmox interface had been on a separate VLAN at some point.
The right way to contact the PC was to go through the GW. But that was never the case.

As for fixing this... I still have physical access to the host. I guess I'll start with a screen and keyboard. It's going to be fun in that closet.
Since I seem to have messed this up from the guest, does someone have an idea for fixing it from there?
Or any idea what mistake I made earlier?

[dseven]

It sounds like the netmask is set incorrectly on the proxmox management interface - it should be 10.1.1.12/24 - do you have it set to /32, maybe?

[EricPerl]

Yes...
This was actually on my TODO of things to investigate.
I don't use static IPs much but know enough that they're typically set with a 255.255.255.0 mask (/24 in CIDR).
It's also what I would have gotten from DHCP.
I had OPN default to /32 on a management interface once, and adjusting it back to /24 had a side effect I didn't expect so I put that on my TODO and left the /32 (and made the corresponding adjustment on proxmox). Not sure what I was thinking.

I had regained access to my host last night after putting it in a VLAN and accessing it from outside the VLAN.

Now I'm left with double-checking that odd side effect I mentioned above.