I have an application and want to start a firefox where all network traffic from firefox goes through the application which does *magic* (doesn't really matter what it does). The idea I have is to open a tcp socket and set a http proxy localhost:port for firefox. That way all (relevant) network traffic from firefox is redirected to the apppication. So far that works just fine. My problem now is that this opens a port in the system usable by any user to access the *magic* as well. And that gets me to my problem. To protect the tcp socket I want to start firefox in a container with for example bubblewrap. Again this works fine but now firefox can't communicate with the application. How do I open a tcp socket in the application (which is outside the container) that is then reachable only inside the container? Or some other way to create a socket only firefox can access?

Is there any way that I can make networkmanager to assign some unique names or device derrived name instead of Auto Ethernet so that we can avoid the names conflict? After I've upgraded to Ubuntu Vivid which uses systemd(though I'm not sure if it's directly related or it's just a bug / regression of network-manager) both of my mobile broadband devices get the "Auth Ethernet" name and are unable to get connected simultaneously. I can temporarry fix it using nmcli con add type ethernet con-name my-office ifname ens3 but I would rather like to have network-manager handle this automatically (i.e. assign a random / unique conn name). Use case: I have two broadband USB devices and I need to connect to both of them. The issue is that NetworkManager displays them both as Auto Ethernet (duplicate in the network manager applet) and when I try to connect to the second network it errors out `(32) Connection 'Auto Ethernet' is already active on enp0s20u`. When I try to "edit" the connections it displays only one Auto Ethernet connection. /etc/NetworkManager/system-connections also lists only one Auto Ethernet

I have 2x internet connections on a linux box (running slackware btw). The ascii schematic is the following

+------------------+
             |              eth1| --- modem #1 --- internet conn #1 
intranet --- |eth0  server      |
             |              eth2| --- modem #2 --- internet conn #2 
             +------------------+

eth0 ip : 192.168.1.1/24
eth1 ip : 192.168.123.2/29 (def.GW has metric 1), modem1 ip : 192.168.123.1/29
eth2 ip : 192.168.124.2/29 (def.GW has metric 0), modem2 ip : 192.168.124.1/29

NOTE: (I could create a *bond* link but the 2 connections are vastly different and I find it'll be more of a headache. Lets not delve in this path for the duration of this thread). So the 2 internet connections are both -uselessly- in the default netw. namespace where an SSH daemon runs listening on all interfaces. For eth0 and eth2 this works fine. But I cannot ssh to this machine from "inet ip #1". The reason is that while the ssh request ingresses the server normally, in the egress direction the default GW of eth2 is used, so somewhere down the line the connection is not completed and I don't get a password prompt. To circumvent this issue, I decided to split the 2 internet connections in 2 different netns. **Q1 : do you have a better suggestion as to how to ?** using

ip netns add fbns
ip link add link eth1 eth1_ns netns fbns type ipvlan mode l2
ip -n fbns link set lo up
ip -n fbns link set eth1_ns up
ip -n fbns addr add 192.168.123.2/24 dev eth1_ns
ip -n fbns route add default via 192.168.123.1 dev eth1_ns

so far so good , I can nslookup on the internet side from inet conn #1.

root@sk:~# ip netns exec fbns nslookup google.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.187.174
Name:	google.com
Address: 2a00:1450:4017:80f::200e

but the local DNS server (bind) which runs in the default netns cannot be accessed:

root@sk:~# ip netns exec fbns nslookup google.com
;; connection timed out; no servers could be reached

from default netns it works fine

root@sk:~# nslookup google.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	google.com
Address: 216.58.212.14
Name:	google.com
Address: 2a00:1450:4017:800::200e

NOTE2: the dns is not extremely necessary as I only want to be able to access the server from the internet side, but it essential that I can access modem's #1 webpage for configuration. There are 2 solution that I attempted, in order to circumvent this issue but none of the 2 worked: Solution 1. use socat --------------------- no sure exactly how to use this correctly but internet suggested:

ip netns exec fbns socat UDP4-RECVFROM:53,fork exec:'socat STDIO "UDP4-SENDTO:localhost:53"',nofork

I also tried the opposite, and both at the same time

socat UDP4-RECVFROM:53,fork exec:'ip netns exec fbns socat STDIO "UDP4-SENDTO:localhost:53"',nofork

but neither worked Solution 2. use ipvlan on eth0 ---------------------- here I simply added the eth0 in the same manner in the netns and added a subnet forwarding towards the default netns. I probably didn't do it properly but I am not sure if ipvlan is even the right construct here.

ip link add link eth0 eth0_ns netns fbns type ipvlan mode l2
ip -n fbns link set eth0_ns up
ip -n fbns addr add 192.168.1.2/24 dev eth0_ns
ip -n fbns route add default via 192.168.1.1 dev eth1_ns

so I am not sure how to achieve a tcp and (perhaps) udp bridge. **Q2: can you please point me in the right direction?** Thank you!

The ip-vrf manual reads : >A VRF provides traffic isolation at layer 3 for routing, similar to how a VLAN is used to isolate traffic at layer 2. Fundamentally, a VRF is a separate routing table. At the same time, The iproute2 ip command allows to deal with multiple separate routing tables by using the table keyword. Moreover, Linux network namespaces, which have been popularized by containers, also allow to separate routing tables (and devices, and […]). So what's the difference between VRFs and iproute2's multiple routing tables, and network namespaces ? Are there some things you can do with one and not the other ? Or is that fundamentally the same mechanism with different names ?

I have a physical network with several VLANs. One of my computers (my main workstation) is connected to two different VLANs on this network, one tagged, the other not. I have successfully set this computer up on both VLANs by making a VLAN clone interface, but I discovered that in order to actually receive packets on that interface I had to change the MAC. It seems that the Linux network stack (or maybe the acceleration on the card) looks at the MAC and if it matches, ignores the VLAN tag. I now want to attach this interface to a bridge somehow and then also have containers attach to this same bridge. I know enough about how containers are constructed that I can do this by hand after whatever container system I'm using (podman in this case) sets the container up. The reason I want this is that I'm working on an IPv6 broadcast/multicast protocol that will only work for a local LAN, and in order to test it, I want to have several copies of the servent running in different containers so they can communicate with each other. I've tried this in the obvious way, but none of the packets that are explicitly destined for one of the containers ever makes it to them. I suspect this is because the card or the Linux network stack is just dropping them at the physical interface when their destination MAC doesn't match any of the MACs assigned to the interface. What would be a good way to accomplish this? Should I ask this on Server Fault or Stack Overflow instead?

When I use separate network namespace, I often set up networking there using veth: ip link add type veth ip link set veth0 netns 1 ifconfig veth1 192.168.60.2 ip route add default via 192.168.60.1 This includes unnecessary random MAC addresses for this "virtual Ethernet". For example in other mechanism (TUN/TAP) there are two modes: "tap" for Ethernet-like mode and "tun" for IP mode (i.e. without ARP, MAC address, neightbors, frame headers, promisc mode and other extra entities). Maybe there is similar "other mode" for veth? | connects | networking level ---------------------------------------- tap | IF to userspace | Ethernet tun | IF to userspace | IP veth | two IFs together | Ethernet I want | two IFs together | IP

I would like to run a new process (for example an xterm) in another network namespace. This could be done like this: sudo ip netns exec otherns sudo -u $USER xterm This command looks a bit complicated and involves running a sudo which runs ip which runs sudo which runs the final xterm. Is there a more direct way to run a process in a new namespace? I was thinking of writing a own small (SUID or capability enabled) binary which switches namespace restores permissions and user and runs the command, but shouldn't there already be some standard tool doing exactly that? This would allow me to simply call something like: runns otherns xterm

I am facing this issue while creating network namespace with following command in kernel 3.10.

bash# ip netns add ns1
mount --bind /var/run/netns /var/run/netns failed: Invalid argument

debugshell# strace ip netns add ns1
execve("/sbin/ip", ["ip", "netns", "add", "ns1"], [/* 14 vars */]) = 0
brk(0)                                  = 0x1aaa000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f947281f000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=25839, ...}) = 0
mmap(NULL, 25839, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7f9472818000
close(5)                                = 0
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0755, st_size=14640, ...}) = 0
mmap(NULL, 2109720, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f94723fb000
mprotect(0x7f94723fe000, 2093056, PROT_NONE) = 0
mmap(0x7f94725fd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x2000) = 0x7f94725fd000
close(5)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\31\2\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0755, st_size=1716712, ...}) = 0
mmap(NULL, 3828864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f9472054000
mprotect(0x7f94721f1000, 2097152, PROT_NONE) = 0
mmap(0x7f94723f1000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x19d000) = 0x7f94723f1000
mmap(0x7f94723f7000, 15488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f94723f7000
close(5)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9472817000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9472816000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9472815000
arch_prctl(ARCH_SET_FS, 0x7f9472816700) = 0
mprotect(0x7f94723f1000, 16384, PROT_READ) = 0
mprotect(0x7f94725fd000, 4096, PROT_READ) = 0
mprotect(0x7f9472820000, 4096, PROT_READ) = 0
munmap(0x7f9472818000, 25839)           = 0
socket(PF_NETLINK, SOCK_RAW, 0)         = 5
setsockopt(5, SOL_SOCKET, SO_SNDBUF, , 4) = 0
setsockopt(5, SOL_SOCKET, SO_RCVBUF, , 4) = 0
bind(5, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(5, {sa_family=AF_NETLINK, pid=29653, groups=00000000}, ) = 0
mkdir("/var/run/netns", 0755)           = -1 EEXIST (File exists)
mount("", "/var/run/netns", "none", MS_REC|MS_SHARED, NULL) = -1 EINVAL (Invalid argument)
mount("/var/run/netns", "/var/run/netns", 0x434746, MS_BIND, NULL) = -1 EINVAL (Invalid argument)
write(2, "mount --bind /var/run/netns /var"..., 68mount --bind /var/run/netns /var/run/netns failed: Invalid argument
) = 68
exit_group(-1)                          = ?
+++ exited with 255 +++

I'm trying to set up two network namespaces to communicate with eachother. I've set up two namespaces, ns0 and ns1 that each have a veth pair, where the non-namespaced side of the veth is linked to a bridge. I set it up like this:

ip link add veth0 type veth peer name brveth0
ip link set brveth0 up

ip link add veth1 type veth peer name brveth1
ip link set brveth1 up

ip link add br10 type bridge
ip link set br10 up

ip addr add 192.168.1.11/24 brd + dev br10

ip netns add ns0
ip netns add ns1

ip link set veth0 netns ns0
ip link set veth1 netns ns1



ip netns exec ns0    ip addr add 192.168.1.20/24 dev veth0
ip netns exec ns0    ip link set veth0 up
ip netns exec ns0    ip link set lo up

ip netns exec ns1    ip addr add 192.168.1.21/24 dev veth1
ip netns exec ns1    ip link set veth1 up
ip netns exec ns1    ip link set lo up


ip link set  brveth0 master br10
ip link set  brveth1 master br10

As expected, I can ping the interface in ns0 from ns1.

$ sudo ip netns exec ns1 ping -c 3  192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.189 ms

But, I can't connect the two over TCP. For example, running a server in ns0 :

$ sudo ip netns exec ns0 python3 -m http.server 8080
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/)  ...

I would expect to be able to curl it from ns1, but that yields an error:

$ sudo ip netns exec ns1 curl 192.168.1.20:8080
curl: (7) Failed to connect to 192.168.1.20 port 8080: No route to host

Why is this happening?

# Task I need to unambiguously and without "holistic" guessing find the **peer** network interface of a veth end in another network namespace. # Theory ./. Reality Albeit a lot of documentation and also answers here on SO assume that the ifindex indices of network interfaces are globally unique per host across network namespaces, **this doesn't hold in many cases**: ifindex/iflink **are ambiguous**. Even the loopback already shows the contrary, having an ifindex of 1 in any network namespace. Also, depending on the container environment, **ifindex numbers get reused in different namespaces**. Which makes tracing veth wiring a nightmare, espcially with lots of containers and a host bridge with veth peers all ending in @if3 or so... # Example: link-netnsid is 0 Spin up a Docker container instance, just to get a new veth pair connecting from the host network namespace to the new container network namespace...

$ sudo docker run -it debian /bin/bash

Now, in the host network namespace list the network interfaces (I've left out those interfaces that are of no interest to this question):

$ ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
...
4: docker0:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:34:23:81:f0 brd ff:ff:ff:ff:ff:ff
...
16: vethfc8d91e@if15:  mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether da:4c:f7:50:09:e2 brd ff:ff:ff:ff:ff:ff link-netnsid 0

As you can see, while the iflink is unambiguous, but the link-netnsid is 0, despite the peer end sitting in a different network namespace. For reference, check the netnsid in the unnamed network namespace of the container:

$ sudo lsns -t net
        NS TYPE NPROCS   PID USER  COMMAND
...
...
4026532469 net       1 29616 root  /bin/bash

$ sudo nsenter -t 29616 -n ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
15: eth0@if16:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

So, for both veth ends ip link show (and RTNETLINK fwif) tells us they're in the same network namespace with netnsid 0. Which is either wrong or correct under the assumptions that link-netnsids are local as opposed to global. I could not find any documentation that make it explicit what scope link-netnsids are supposed to have. # /sys/class/net/... NOT to the Rescue? I've looked into /sys/class/net/_if_/... but can only find the ifindex and iflink elements; these are well documented. "ip link show" also only seems to show the peer ifindex in form of the (in)famous "@if#" notation. Or did I miss some additional network namespace element? # Bottom Line/Question Are there any syscalls that allow retrieving the missing network namespace information for the peer end of a veth pair?

I have a docker container with the internal ip addr 172.17.0.2, that is connected to the docker's virtual interface with ip 172.17.0.1 on my host:

root@ldc1:/# ip a
1: lo:  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
10: eth0@if11:  mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
root@ldc1:/# ip route
default via 172.17.0.1 dev eth0 
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2 
root@ldc1:/#

I'm able to ping a 172.17.0.1 inside a running docker container. Then I add a network ns and tune it:

#!/bin/bash

# create namespace
ip netns add ns2
ip link add veth20 type veth peer name veth21
ip link set veth21 netns ns2

# configure namespace
ip netns exec ns2 ip link set dev lo up
ip netns exec ns2 ip addr add 10.1.200.4/24 dev veth21
ip netns exec ns2 ip link set dev veth21 up
ip netns exec ns2 ip route add default via 10.1.200.3 dev veth21

# configure global ns
ip addr add 10.1.200.3/24 dev veth20
ip link set dev veth20 up

# enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

Then I open namespace and try to ping 172.17.0.1

root@ldc1:/home/vscode/wc# ip netns exec ns2 bash
root@ldc1:/home/vscode/wc# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.023 ms
^C
--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.023/0.023/0.023/0.000 ms
root@ldc1:/home/vscode/wc# ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1) 56(84) bytes of data.
^C
--- 172.17.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

And pings do not pass. If I try to ping an adapter inside global ns (172.17.0.2) it works fine. Have anybody an idea what is wrong and why ping packets can not reach 172.17.0.1? What I'm not taking into account? _________________________ (Upd): I decided that 10.1.200.x is not a good choice if an address 10.200.1.4 should be accessed from the host machine for example. So I've changed my script in the next manner:

!/bin/bash

ifconfig eth0 172.17.0.2/24
ip route add default via 172.17.0.1 dev eth0

# create namespace
ip netns add dcns2
ip link add veth20 type veth peer name veth21
ip link set veth21 netns dcns2

# configure namespace
ip netns exec dcns2 ip link set dev lo up
ip netns exec dcns2 ip addr add 172.17.1.4/31 dev veth21
ip netns exec dcns2 ip link set dev veth21 up
ip netns exec dcns2 ip route add default via 172.17.1.5 dev veth21

# tune global ns paired iface
ip addr add 172.17.1.5/31 dev veth20
ip link set dev veth20 up

# enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

So: - On the host I have an interface with the name docker=172.17.0.1/16. - Global NS in docker container has an eth0=172.17.0.2/24 and veth20=172.17.1.5/31 - dcns2 namespace has veth21=172.17.1.4/31 So now in my host console I can ping 172.17.0.2, 172.17.1.5, but I can not 172.17.1.4. And inside dcns2 I can ping 172.17.0.2, 172.17.1.5 and can not 172.17.0.1. Although it should work I'd guess.

@ldc1:/home/vscode/wc# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

________ (Upd2): I sniffed my docker0 iface and found out that the pings reach out the interface. So I added the next route:

ip route add 172.17.1.4/31 via 172.17.0.2 dev docker0

and that helped. Thanks.

I have this local network service and this client program needing to access it. I am running them both as an unprivileged user. I am looking for a way to sandbox the client using firejail, in a way that it cannot access network, except for localhost (or even better, except for that service). first thing I tried was of course firejail --net=lo program But it didn’t work. Error: cannot attach to lo device I think I could work around it by creating a virtual network interface, for example veth0 and veth1, moving veth1 to a new network namespace in which I’d run the service and using firejail to restrain the client to veth0 Is there a way to actually automate this setting in a firejail profile, so that all of these interfaces are created and veth1 is moved when I type firejail server (without having to run anything as root)? Or is there a simpler way solve this problem? (I cannot run both the client and the service in the same namespace, because the service needs to access the network)

I have here a process from which I do not want to access the internet, except from my company VPN. My company VPN is using a tun device. If the VPN is not active or does not work, the expected behavior is that the process does not see any network et all. The goal is prevent the guys on the server side to know anything about my VPN-less connection. It is a desktop process and running it with a different user would not what I would really love to. My current best idea is to use some network namespace, create a routing behind it, mark the packages, and then use the iptables rules to disallow marked packages out of the VPN interface. That would work, but I would prefer some more simple way. Does it exist?

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments:

apt install netcat-traditional

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1

ip netns exec ns2 nc -u -l -p 8080

then I run this from another terminal:

ip netns exec ns1 nc -u 2.3.4.5 8080  ns2 my_veth2 gives the same output

So I tried creating the ARP table entry manually...

sh ip -n ns1 neighbour add 2.3.4.5 dev my_veth1 lladdr $(ip netns exec ns2 cat /sys/class/net/my_veth2/address)

And now apparently the UDP packet is being sent

$ ip netns exec ns1 tcpdump -l -i my_veth1 00:24:15.164245 IP 1.2.3.4.36170 > 2.3.4.5.8080: UDP, length 39

> ns2 my_veth2 gives the same output

However, the first terminal that has the UDP netcat server running still doesn't output anything. Why?

---

**EDIT 3:** After doing all of the above, I tried assigning an IP address to my_veth2:

sh ip -n ns2 address add 2.3.4.5 dev my_veth2

And now, when I send the UDP packet, I get this error in the terminal that is running netcat in listen mode:

sh no connection : Network is unreachable ``` Why? I mean, of course the network is unreachable, but that shouldn't stop the server from receiving and displaying UDP packets. In fact, that error is only displayed when it receives the UDP packet. So even if it knows that it can't answer, it should be able to receive and display the message, right?

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments:

apt install -y netcat-traditional tcpdump inetutils-ping

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1

ip -n ns2 address add 2.3.4.5 dev my_veth2

Then I run these commands in different terminals:

# Terminal 1
ip netns exec ns1 tcpdump -l -i my_veth1

# Terminal 2
ip netns exec ns2 tcpdump -l -i my_veth2

# Terminal 3
ip netns exec ns1 ping 2.3.4.5

I get the same output in terminals 1 and 2:

02:40:27.511438 ARP, Request who-has 2.3.4.5 tell 1.2.3.4, length 28
02:40:27.511438 ARP, Request who-has 2.3.4.5 tell 1.2.3.4, length 28
02:40:27.511438 ARP, Request who-has 2.3.4.5 tell 1.2.3.4, length 28
...

veth2 has the IP address 2.3.4.5 and is receiving the ARP request. Why doesn't it send an answer? It only answers when I configure a routing table entry:

ip -n ns2 route add 1.2.3.0/24 dev my_veth2

But it shouldn't be necessary since the MAC address of the network interface that veth2 should respond to is already encoded in the request it is responding to.

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments: > If you have seen [this post](https://unix.stackexchange.com/q/787076/203214) , it's the same setup but with the ip address 2.3.4.5 assigned to my_veth2 and the routing table entry 1.2.3.0/24 to make sure data can be sent and received from each network namespace.

# Terminal 1

apt install -y netcat-traditional tcpdump

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1
ip -n ns2 address add 2.3.4.5 dev my_veth2
ip -n ns2 route add 1.2.3.0/24 dev my_veth2

ip netns exec ns2 nc -l -p 8080

then I open 2 more terminals to run tcpdump in each network namespace:

# Terminal 2
ip netns exec ns1 tcpdump -i my_veth1

# Terminal 3
ip netns exec ns2 tcpdump -i my_veth2

then I open one more last terminal to send data to the netcat server in ns2 from ns1:

# Terminal 4
ip netns exec ns1 nc 2.3.4.5 8080 <<< 'Hello world from network namespace ns1'

Results: * The message sent from Terminal 4 is printed in Terminal 1, as expected. * No packets are being shown in either tcpdump. **WHY?**

I'm trying to run socat forward ttyACM0 into UDP. It works with command.

socat UDP-LISTEN:14550,fork,reuseaddr FILE:/dev/ttyACM0,b57600,raw

Problem is, I need to access socat via ip address, which is inside netns. I tried to enter this command:

ip netns exec int socat UDP-LISTEN:14550,fork,reuseaddr FILE:/dev/ttyACM0,b57600,raw

, which displays error:

2024/10/10 14:14:37 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:38 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:39 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:40 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:41 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:42 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:43 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:44 socat E write(5, 0x1d54000, 44): Connection refused
2024/10/10 14:14:45 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:46 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:47 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:48 socat E write(5, 0x1d54000, 40): Connection refused
2024/10/10 14:14:49 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:50 socat E read(5, 0x1d54000, 8192): Connection refused

How to properly run socat inside netns?

A couple of days ago I had a motherboard failure and as a result I bought a new computer. I swapped in the old hard drives and after a couple of hiccups, everything was nearly the same again. It is running Linux Mint 20.3 Cinnamon and since it's literally the same drives, nothing but the hardware and some drives has changed. I have been using openvpn to connect to a vpn service in a network namespace using, I think, a relatively common strategy of having an 'up' 'route-up' 'down' script that openvpn uses. I did change the dev name from 'eth0' to 'enp1s0' as that's how the new ethernet device showed up. This is the 'up' portion: ip netns add vpn ip link add dev veth0 address "" type veth peer name veth1 ip link set veth0 netns vpn ip link set veth1 up ip link set enp1s0 down ip addr flush dev enp1s0 ip link set enp1s0 up ip link add br0 type bridge ip link set enp1s0 master br0 ip link set veth1 master br0 ip addr add xx.xx.xx.58/24 dev br0 ip link set br0 up ip route flush default ip route add default via xx.xx.xx.1 ip netns exec vpn ip link set lo up ip netns exec vpn ip addr flush dev veth0 ip netns exec vpn ip addr add xx.xx.xx.100/24 dev veth0 ip netns exec vpn ip link set veth0 up ip netns exec vpn /usr/sbin/iptables -F OUTPUT ip netns exec vpn /usr/sbin/iptables -A OUTPUT -d $trusted_ip -j ACCEPT ip netns exec vpn /usr/sbin/iptables -A OUTPUT -d xx.xx.xx.0/24 -j ACCEPT ip netns exec vpn /usr/sbin/iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT ip netns exec vpn /usr/sbin/iptables -A OUTPUT -o tun0 -j ACCEPT ip netns exec vpn /usr/sbin/iptables -P OUTPUT DROP ip link set dev "$1" up netns vpn mtu "$2" ip netns exec vpn ip addr add dev "$1" \ "$4/${ifconfig_netmask:-30}" \ ${ifconfig_broadcast:+broadcast "$ifconfig_broadcast"} and then 'route-up': ip netns exec vpn ip route add default via "$route_vpn_gateway" dev tun0 I've had this working for years and now when it runs, the global namespace and the netns can ping each other, but nothing else. I've confirmed that */proc/sys/net/ipv4/ip_forward* is still 1. I've confirmed that all of the routing globally and in the **netns** looks like I expect and as it always has. I've confirmed that the global iptables forward policy is "ACCEPT". I've tried walking through the script steps one-by-one any number of times, and there are no errors but it never works. I've tried walking through a number of really basic netns tutorials to try and sort out what happening. For example this one: Linux Network Namespaces, An Easy Guide To Establish And Link Seperated Environments It creates and connects two network namespaces by two different methods: with a bridge and without one. Perhaps notably, the second method described using a bridge, would not work for me and the two netns's couldn't ping each other. I'm at a bit of a loss as to why this might has suddenly stopped working. Any suggestions?

[This question](https://unix.stackexchange.com/questions/396175/how-do-i-connect-a-veth-device-inside-an-anonymous-network-namespace-to-one-ou) hints that it is possible to create a veth (which normally requires root) from inside a user and network namespace, and indeed:

user@host$ unshare --user --net -r =bash
root@namespace# ip link add veth0 type veth peer name veth0 netns 1
root@namespace# ip link
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth0@if3:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 4a:b9:93:89:bd:d1 brd ff:ff:ff:ff:ff:ff link-netnsid 0

The other end of the veth does appear on the host:

user@host$ ip link
...
3: veth0@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 62:02:c7:8c:58:77 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Unfortunately, it does not seem possible to use it in a practical way as a regular user, because any modification requires root, including bringing the interface up:

user@host$ ip link set veth0 up
RTNETLINK answers: Operation not permitted

Is this actually possible, and did I miss something? Container technologies like Podman makes use of custom usermode TCP/IP stacks ([slirp4netns](https://github.com/rootless-containers/slirp4netns) or [passt/pasta](https://passt.top/passt/about/)) when run in rootless mode, which work _in addition_ to the normal kernel networking stack. Is there a documented reason why using (if yes) or developing (if no) such a feature was not pursued while developing those alternative stacks?

I recently became aware of solutions like [slirp4netns](https://github.com/rootless-containers/slirp4netns) or [passt/pasta](https://passt.top/passt/about/) which essentially work around the fact that you can't create a pair of [veth](https://www.man7.org/linux/man-pages/man4/veth.4.html) network interfaces without root (or CAP_NET_ADMIN). Before user namespaces became widely available, changing the network configuration was indeed originally restricted to the superuser. Is there a documented reason why it was deemed "easier" to create a whole entire TCP/IP stack and/or complex abstraction layers rather than just allowing users to create their own pairs? Was it difficult to implement a user permission scheme on top of the networking configuration tools, or are there security reasons why allowing non-root users to modify the network configuration of interfaces they themselves created would be a bad idea?