Score:0

Dual-NIC Ubuntu Netplan configuration for webapp via DMZ and internet via LAN

mq flag

I have a Dual homed Ubuntu 22.04 LTS Server that has one NIC in DMZ and the other in LAN. I've been wrestling with the netplan configuration and my searching has found many mixed recommendations on how to accomplish my desired configuration due to the recent changes in gateway configurations and routes. I've read the netplan documentation: https://netplan.readthedocs.io/en/latest/netplan-tutorial/

Currently I have the following settings:

$ ip route:

default via 192.168.2.2 dev eth0 proto static metric 100 onlink 

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 

172.18.0.0/16 dev br-e9fa8283d45d proto kernel scope link src 172.18.0.1 

192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.39 

192.168.14.0/24 dev eth1 proto kernel scope link src 192.168.14.2 

Current netplan .yaml config file:

network:

  version: 2

  renderer: networkd

  ethernets:

    eth0:

      addresses:

        - 192.168.2.39/24

      dhcp4: no

      routes:

        - to: 0.0.0.0/0

          via: 192.168.2.2

          metric: 100

          on-link: true

      nameservers:

        addresses:

          - 192.168.2.29

          - 192.168.2.10

    eth1:

      addresses:

        - 192.168.14.2/24

      dhcp4: no

      routing-policy:

        - from: 192.168.14.0/24

          table: 199

      routes:

        - to: 0.0.0.0/0

          via: 192.168.14.1

          metric: 100

          table: 199
$ ip rule list

0:   from all lookup local

32765:   from 192.168.14.0/24 lookup DMZ proto static

32766:   from all lookup main

32767:   from all lookup default

Current rt_table:

xxx@xxx:/etc/iproute2$ cat /etc/iproute2/rt_tables

#

# reserved values

#

255   local

254   main

253   default

0   unspec

#

# local

#

#1   inr.ruhep

199   DMZ
xxx@xxx:/etc/iproute2$ ip -d route show table 199

unicast default via 192.168.14.1 dev eth1 proto static scope global metric 100 

When I attempt to replace the route in this table 199 with the following:

sudo ip r replace default via 192.168.14.1 dev eth1 proto static scope link metric 100 onlink table 199

i receive the following error: "Error: Nexthop has invalid scope."

What I'm trying to accomplish:

1. Allow internet access and Local Networking to go out via LAN connection.

2. Allow inbound traffic from our NATed Public IP to the DMZ Interface: 192.168.14.2 to reach our web application and be returned on the originating NIC (DMZ).

Currently with this configuration I can access the internet, but my web application times out. I've done packet tracing to determine that the flag [S] traffic is making it into the Ubuntu server, but no replies are heading back out.

What I'm finding is if I replace the default route - default via 192.168.2.2 dev eth0 proto static metric 100 onlink with default via 192.168.14.1 dev eth1 proto static metric 100 onlink then my web application works correctly and I see the return traffic, but then my server has no internet access as I need that traffic (updates, etc) to go out the LAN interface.

Please provide some direction on what netplan configration I need to have to allow the dual-NIC to work and persist on reboot.

Thank you in advance for any help.

[EDIT:1] Thank you - I have read completely through netplan.io and tried different configurations to no avail. I would love to have someone who has successfully done this if possible with netplan in it's modern version, as we've been stabbing at this for 2 weeks now with the questions posted on two other forums and no resolve because people are recommending deprecated options. I have removed the 'on-link: true' and it did not change any behavior.

[EDIT:2] My internal access site 192.168.2.39:8444 works just fine in the above configuration. I cannot however access the other Public facing site from the DMZ 192.168.14.2:443. I can change the default route either using routing tables or in the main table: default via 192.168.2.2 dev eth0 proto static metric 100 onlink to default via 192.168.14.1 dev eth1 proto static metric 100 onlink adn then my public site works great, but I have no access to my internal application. This seems like such an easy problem to solve on Windows, but I am not proficient with routing configuration in Linux.

[EDIT:3] I did packet capture with tcpdump and can see the public traffic having only one side of the conversation with Flag [S], but no return traffic via DMZ using this command: sudo tcpdump -i eth1 -n port 443 -S -vv. I can see the replies attempting to go out eth0 using this command sudo tcpdump -i eth0 -n port 443 -S -vv

sudo tcpdump -i eth1 -n port 443 -S -vv
18:46:03.273544 IP (tos 0x0, ttl 47, id 62306, offset 0, flags [none], proto TCP (6), length 60)
    xxx.xx.xxx.xx.60921 > 192.168.14.2.443: Flags [S], cksum 0x0b11 (correct), seq 3026599530, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS val 178557874 ecr 0], length 0
sudo tcpdump -i eth0 -n port 443 -S -vv
18:46:51.177103 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.14.2.443 > xxx.xx.xxx.xx.18874: Flags [S.], cksum 0xbc3f (incorrect -> 0x7356), seq 78744143, ack 2652949040, win 65160, options [mss 1460,sackOK,TS val 1512654855 ecr 178596451,nop,wscale 7], length 0

[EDIT:4] Could this have to do with the fact that we have 2 docker containers that need to respond on different physical NICs? the DMZ container needs to allow and respond to port 80/443 on eth1. the LAN container needs to respond to port 8443 on eth0 and access internet for updates. I wonder if the docker netwokring needs attention. HEre is the current route -e:

$ sudo route -e
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         _gateway        0.0.0.0         UG        0 0          0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U         0 0          0 br-e9fa8283d45d
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.14.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1

It looks like all of the docker containers use br-e9fa8283d45d and it is default gateway 0.0.0.0, which in turn points to eth0. Would that cause incoming requests on eth1 to be routed to eth0 on replies?

Thank you-

waltinator avatar
it flag
Please see `https://netplan.io` and `https://netplan.io/examples`.
us flag
The only things I see of issue here are that you should not be specifying `on-link` to netplan. This is only necessary when specifying a route without a gateway which is not applicable here. Likewise, your `scope link` in the `ip` command looks incorrect and may be the cause of your error message.
mark2tech avatar
mq flag
I have added two edits above, but we're still in the same situation with no one having provided a solution to allow the two simple networking requirements listed above. I don't understand why this has been made so difficult when this is a standard DMZ host in any environment. Do I simply need to point my internet traffic out the DMZ firewall for now? Any other simple changes I can do to make this work would be greatly appreciated.
Score:0
si flag

See the example below and try to implement You can also check this article https://technokona.com/how-to-add-static-routes-in-ubuntu-with-netplan/

network:
    ethernets:
        eth0:
            addresses:
            - 192.168.1.100/24
            gateway4: 192.168.1.1   #Your default gateway to the internet 
            nameservers:
                addresses:
                - 8.8.8.8
        eth1:
            addresses:
            - 10.1.1.130/26
            routes:
            - to: 10.1.2.100  # Your We ABB IP address
              via: 10.1.1.129   #Gateway to be used by Ubuntu to WebAPP
    version: 2
Artur Meinild avatar
vn flag
The `gateway4` property is deprecated, and has been replaced by `routes: - to: xxx via: yyy` as indicated under `eth1`.
MchiloTech avatar
si flag
Okay sure, in this case he need to add routers: -to: 0.0.0.0 via Default gateway. Thanks @ArturMeinild for reminder
mark2tech avatar
mq flag
So far none of the suggestions have 1. dealt with the version of netplan that I am using, and 2. done anything other than point me to documentation that I've already read. You can see that I've clearly used 0.0.0.0/0 as my default gateway on eth0. I am still looking for any type of troubleshooting that will lead to the return traffic on eth1 being properly routed over eth1 and not eth0.
Score:-1
si flag

In this case you will probably need to enable static routing torwards the the Web application. The default gateway should always be towards the internet gateway but for specific web apps on the LAN you need to enable static routing, Specify the actual Web APP IP addresses

mark2tech avatar
mq flag
When you say 'Specify the actual Web APP IP addresses', what does that mean? Where do I specify these?
MchiloTech avatar
si flag
Check this Link. It has examples, https://technokona.com/how-to-add-static-routes-in-ubuntu-with-netplan/
mark2tech avatar
mq flag
I have reviewed this article. Again, it is not directly applicable to the issue I have of traffic coming in on eth1 and improperly routed on eth0 with the routing tables appearing to be setup correctly using my table 199. I'm looking for a way to troubleshoot this routing issue or someone who is familiar with setting up the netplan+iptables2 routing in a DMZ+LAN environment where I want internet traffic to route via LAN, but incoming web requests to u-turn via the DMZ NIC.
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.