I've got one machine on Hetzner running Proxmox and a VM with OPNsense 25.1. The host has Hetzner's default single IP, and I want to keep it like that (if the router VM fails to start).
Then I have 2x extra IP's, which are on separate MAC's, added as two separate NIC's in the Opnsense VM. I run into OPNsense's (or FreeBSD's?) limit of having the same gateway defined only once.
So from what I gather, and here's where I want some input;
- If I chose to reset the MAC in Hetzner Robot on extra-ip-1, can I then assign it on to the same MAC as extra-ip-2?
- If that works, and I have both IP's on the same MAC, do I then have one as primary on the interface, and add the second as a Virtual IP?
- If those two work, is it then the outbound NAT settings which determine which public IP is shown for what service, and I can choose which one with "Translation/Target"?
- For inbound/forwards, I suppose I should select which the incoming IP is within the rule, not just the interface.
I'll probably pull the trigger and experiment on this, when I've got a bit of time on my hands. But would like the extra input if possible.
For future reference, I've solved it, but not exactly in the fashion I had in mind. But it works.
Each IP on Hetzner is on its own MAC. I've added these as NIC's in a bridge in Proxmox to OPNsense.
I've assigned these two NIC's as WAN1 and WAN2 (technically wan and opt1). This is same as previously written.
The difference is I've changed them both to DHCP, instead of static IP. I read it somewhere on this forum, that it allows the same gateway IP added via DHCP, but not manually.
In outbound NAT, I've added LAN-out-via-WAN1 and LAN-out-via-WAN2.
In Firewall / LAN, I've added rules[1] that force gateway WAN1 or WAN2 depending on which machine makes the request. Et voila, it works!
[1] FW Rules:
Proto: IPv4
Source: wan1_machines (this is an alias containing the source IP's)
Dest: any
Gateway: WAN1_DHCP
Proto: IPv4
Source: NOT wan1_machines (inverted rule)
Dest: any
Gateway: WAN2_DHCP
The only thing not working properly right now is hairpinning port forwards. Will need to dig into this more, but also solvable with DNS overrides.
Hope this helps someone in the future.