I have been using two bridges: one for wired connections and one for my wireless network. I read somewhere that this is bad as only the first bride can be hardware offloaded.
As part of this configuration I used a dst-nat rule to redirect traffic from my LAN to my public IP address to an internal server IP address, similar to a hairpin NAT.
Tonight I merged the two bridges and the dst-nat rule stopped working. My incoming port forwarding rules continue to work without issue. After spending several hours troubleshooting I setup local DNS and called it a night. Does anyone know why merging the bridges broke the redirect?
probably your mitm redirect should be easy enough as long as your target server is on separate interface than those wired and wireless lan. let us say a dmz interface for the server?
dst-nat should be enough. or you can give us some simple drawing about your network?
@wiseroute I “merged” the bridges by taking all of the ports that were on bridge 2 and adding them to bridge 1. Bridge 2 consisted of wireless access points which had their own subnet, DHCP server, etc…
What do you mean by “on a separate interface”? Should I remove the ports I use for my homelab servers from the bridge? That would negate the performance benefits I sought by only having 1 bridge in the first place.
My network is super simple. I have a MikroTik RB4011iGS+5HacQ2HnD-IN. My fiber internet is plugged into port 1. All other ports are bridged. Two ports are used for some homelab servers running docker containers, e.g. pi-hole, and two ports are used for dedicated wireless APs. I do have some fancy firewall rules to prevent port scans but they shouldn’t affect a dsn-nat rule.
What I’m trying to accomplish is to be able to connect to mydomain.com hosted on my homelab without having to rely on pi-hole for custom DNS. This causes some annoying issues that the dst-nat rule would fix if I can get it working, e.g. when switching from WiFi to mobile on my phone I have to disable/re-enable my WireGuard VPN to force the DNS to refresh. If it always uses the public IP it wouldn’t be an issue.
@anav I’d rather not posy my config if possible. It’s huge with many comments, e.g. devices labeled with family names, etc…
Apologies for double posting. I should have read the freak’n manual.
Hairpin NAT gave me the background I was looking for. Very insightful. Then I followed the advice from Hairpin NAT - The Easy Way for my config. Hopefully this helps someone else in the future.
Can anyone explain why it worked without the hairpin rule when I had 2 bridges? Maybe it had nothing to do with the bridges at all and more to do with being on a different subnet?
This. If internal server and internal client are not in same IP subnet, then hair-pin NAT is not necessary. Because they have to “talk” via your router anyway and firewall is able to un-do NAT without “pulling” return traffic by applying the SRC-NAT rule (which makes hair-pin NAT operational).