Join Log in
Score:0
fox91 avatar Server

Respond to inbound connections from multiple gateways on a single interface

cn flag
fox91

I have a network with multiple gateways (gw1: 10.0.0.1 and gw2: 11.0.0.1).

My server (Ubuntu 20.04) have one NIC with multiple addresses (eth0:gw1: 10.0.0.55 and eth0:gw2: 11.0.0.55).

Each gateway provide internet access and have a NAT rule configured to forward ports 80 and 443 to my server.

In my server I've configured nginx to respond to both address and from internal network it works like I've expected.

The problem is: it doesn't respond at calls coming from both public IPs (connection timeout) but only to those coming from the default gateway.

Following the Netplan documentation I tried dozens of configurations but I couldn't get responses from both public IPs, always only from the default one (they both work, I tried swapping them and only using them one at a time to confirm).

I'm not a network engineer so I don't know if is a thing possible to do or not. Is it possible?

My actual netplan config:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      optional: true
      addresses:
        - 10.0.0.55/24:
            label: "eth0:gw1"
        - 11.0.0.55/24:
            label: "eth0:gw2"
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1
          - 8.8.8.8
          - 8.8.4.4
      routes:
        - to: default
          via: 10.0.0.1
        - to: default
          via: 10.0.0.1
          metric: 200
          table: 101
        - to: default
          via: 11.0.0.1
          metric: 200
          table: 102
      routing-policy:
        - to: 10.0.0.0/24
          from: 10.0.0.0/24
          table: 101
        - to: 11.0.0.0/24
          from: 11.0.0.0/24
          table: 102

I don't know if I need more or less options in my config (ex: routing-policy?)

101
1 + 0
Score:1
avatar Server
pt flag
larsks

It looks like your policy rules are incorrect. You have:

      routing-policy:
        - to: 10.0.0.0/24
          from: 10.0.0.0/24
          table: 101
        - to: 11.0.0.0/24
          from: 11.0.0.0/24
          table: 102

But for a request coming from outside of your local network, the source address will not be from 10.0.0.0/24; it will be the address of a remote client somewhere on the internet. In a typical configuration, your gateways will not masquerade inbound traffic; they only masquerade outbound traffic so that replies appear to originate at the gateway rather than from the internal server.

That means your to: ... rules are never going to match. You should only match using from: ... (which is the source address for the reply from your server at x.0.0.55/24).

I think you need:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      optional: true
      addresses:
        - 10.0.0.55/24:
            label: "eth0:gw1"
        - 11.0.0.55/24:
            label: "eth0:gw2"
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1
          - 8.8.8.8
          - 8.8.4.4
      routes:
        - to: default
          via: 10.0.0.1
        - to: default
          via: 10.0.0.1
          metric: 200
          table: 101
        - to: default
          via: 11.0.0.1
          metric: 200
          table: 102
      routing-policy:
        - from: 10.0.0.0/24
          table: 101
        - from: 11.0.0.0/24
          table: 102
+ 2
pt flag
larsks
You can see my test environment [here](https://github.com/larsks/sf-example-1130038-two-gateways), which uses [mininet](http://mininet.org/) to create a virtual network topology. The example uses manual configuration rather than netplan.
0
Reply
fox91 avatar
cn flag
fox91
Thanks, it worked perfectly!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.