Dual NICs won't allow Minecraft server from LAN

I'm running Ubuntu Server 22.04 with two NICs configured. It's a VM (Virtual Machine) that has NIC1 on VLAN0 and NIC2 on VLAN10 (without the VM knowing, this is specified in the hosts' bridges).

I use netplan to setup the network configuration:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18: # NIC1 (VLAN0)
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.131/24
      nameservers:
        addresses:
          - 192.168.1.1
        search: []
      routes:
        - to: 192.168.1.0/24
          via: 192.168.1.1
    ens19: # NIC2 (VLAN10)
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.10.103/24
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1
        search: []
      routes:
        - to: default
          via: 192.168.10.1
        - to: 192.168.10.0/24
          via: 192.168.10.1

This seems to work fine for the most part. My firewall (gateway) has all traffic between VLAN blocked except from VLAN0 to VLAN10 for port 25565 (more on this later) and a rule from VLAN10 to VLAN0 for established connections.

Sometimes I get this weird thing that I can ping IP addresses outside of my LAN on both NICs, but I cannot download stuff (wget, curl etc.). Only NIC2 works. I cannot figure out what the problem is and why it works after a reboot.

But the main problem I'm facing is that I'm running a Minecraft server using a Docker container. I have it bound to interface ens19 (NIC2) and the port is 25565 (default MC port). I can access the MC server from outside my LAN using my public IP address, I can access the server from within my LAN using the VMs IP address (NIC2). However, I cannot access the server from within my LAN using my public IP address.

I have confirmed it's not my firewall (gateway) as I can see it is not blocking that connection and it's even accepting it via the rule I explained above for port 25565. I cannot figure this out, it seems to be related to routing, but it clearly works when using the LAN IP address of the server. The return address (source) of the incoming client should be the same no matter if I connect via LAN or public if I'm not mistaken?

I have also confirmed my loopback is working fine, as I can access my webserver on another VM (with only 1 NIC) via my public IP address from within the LAN.

When I use pktstat -n while I try to connect from my LAN to the MC server I can see this:

292.9 8% tcp 192.168.1.217:55701 <-> 192.168.10.103:25565 192.168.1.217 is my computer within the LAN trying to connect to the MC server. However, when specifying the interface pkstat -n -i ens18 it still shows up, even though that is not the interface the MC server is listening on. The packet shows up for both interfaces. I can connect to the server using it's NIC1 IP address and again, packet is visible on both interfaces.

EDIT: When I remove the first interface so I do not have access to my LAN directly and only have the VM network of the 2nc NIC, everything works as it should. This is clearly a dual NIC thing and might be related to Docker containers.

You cannot access the public IP from inside the LAN. That is impossible, because that NAT is provided on the WAN link of the router and those rules do not engage unless the traffic comes from outside->inside. Inside-inside traffic going through the public IP will get dropped. Pinging the WAN address would work because there isn't another NAT or 're-injection' needing to take place for that to succeed.

But, the best way to explain it is that you're traffic will go to the public IP and since it was already routed "once" from inside->outside NIC, the router thinks it's done. The traffic will not be re-injected back down it's own interface. There is simply no way for that to happen. The public address should never work for you. (And, why would you need it to?)

NIC2 is specified as the default route for pings, so all traffic will originate there. NIC1 will only be used in the situation where you are pinging any address on the 192.168.1.0/24 network as this will be the most direct link for that traffic and will preempt NIC2 who just has a "fuzzy" default route.

The curl, whatever else, this is getting firewall rules wrong somewhere. The routers don't make these decisions unless you've installed a filtering rule set on them. For testing, I would disable them all, and make sure what they are is what you expect. Take all the firewall rules off, test, and slowly add things back to them. The usual culprit is not having a "drop all" rule as your last rule. If that isn't the case your rules after it are ignored. Things are dropped before they are evaluated by the rules that permit the traffic. The order matters... All permit rules first, all drops last. The firewall rules are usually "first match" so if the drop is before the allowing rule it will drop every time. That's the only thing I can think of that would cause your problem.