Score:0

Why does the order of network connections in my client machine's /etc/network/interfaces matter to my router?

ck flag

I have a virtual machine running Debian 11, and it needs to connect to two VLANs. From within the building on the local network, I can access it fine through both IPs, but when I'm outside the network using either the router's VPN or the 1:1 NAT on the router, I can only connect to the first network listed in /etc/network/interfaces (from the VPN I can't even ping the second one). Not sure if this is related to the router specifically or if it's some other kind of "more external source".
Why would the order matter? And is there anything I can do to make both work? If I swap them around and reboot, whatever was first in the file when it booted seems to work fine, and what's second in the order only works from a local computer.

A lot of the installation was via instructions I don't understand, so I'll include what seems relevant here, but I may have done something about it wrong

I installed the vlan software (I think?) with

# apt install vlan
# modprobe 8021q && lsmod | grep 8021q

And disabled Gnome's NetworkManager

In /etc/sysctl.conf I've added

net.ipv4.ip_forward=1
net.ipv4.conf.all.arp_filter=0
net.ipv4.conf.all.rp_filter=2

I need to forward port 80 and 443 to above 1024

# iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-ports [new port]
# iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-ports [new port]
# iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports [new port]
# iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports [new port]
# iptables-save | sudo tee /etc/iptables.rules

And /etc/network/interfaces looks like

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# A VPN client can ping this one
auto ens18.200
iface ens18.200 inet dhcp
    pre-up iptables-restore < /etc/iptables.rules

# But not this one
auto ens18.40
iface ens18.40 inet dhcp
    pre-up iptables-restore < /etc/iptables.rules

The router is a Meraki MX250 if that matters


Requested outputs

root:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:56:--:--:-- brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet6 fe80::---:----:----:----/64 scope link
       valid_lft forever preferred_lft forever
3: ens18.200@ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:56:--:--:-- brd ff:ff:ff:ff:ff:ff
    inet 10.26.1.100/22 brd 10.26.3.255 scope global dynamic ens18.200
       valid_lft 623197sec preferred_lft 623197sec
    inet6 fe80::---:----:----:----/64 scope link
       valid_lft forever preferred_lft forever
4: ens18.40@ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:56:--:--:-- brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.114/24 brd 192.168.1.255 scope global dynamic ens18.40
       valid_lft 623198sec preferred_lft 623198sec
    inet6 fe80::---:----:----:----/64 scope link
       valid_lft forever preferred_lft forever
root:~# ip ru
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
root:~# ip r
default via 10.26.1.1 dev ens18.200
10.26.0.0/22 dev ens18.200 proto kernel scope link src 10.26.1.100
192.168.1.0/24 dev ens18.40 proto kernel scope link src 192.168.1.114
root:~# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
root:~# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 39528 packets, 7495K bytes)
 pkts bytes target     prot opt in     out     source               destination
  166  8509 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports [new port]
  215 10964 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports [new port]

Chain INPUT (policy ACCEPT 38823 packets, 7422K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 249 packets, 15870 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   180 REDIRECT   tcp  --  *      lo      0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports [new port]
    3   180 REDIRECT   tcp  --  *      lo      0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports [new port]

Chain POSTROUTING (policy ACCEPT 255 packets, 16230 bytes)
 pkts bytes target     prot opt in     out     source               destination
root:~# tcpdump
-bash: tcpdump: command not found
in flag
This sounds more like a routing our firewall issue, I would like to see your question updated with output from `ip a`, `ip ru`, `ip r`, `iptables -vnL`, `iptables -vnL -t nat`, this should give a better picture of how your machine is actually configured. I'm also assuming that you have issues with access from other subnets, and for that case the `ip r` is most relevant. `tcpdump` can also be useful to you to identify which part of the traffic works and not.
Michael Hampton avatar
cz flag
Why do you load your firewall rules twice?
electron.rotoscope avatar
ck flag
@NiKiZe thanks, updated with those added
electron.rotoscope avatar
ck flag
@MichaelHampton I was thinking I was loading them for each connection, but upon reflection you're right I don't need that at all! I'll remove the second entry
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.