Nixos-container networking NAT icmp_seq=1 Destination Host Unreachable

not-jack · May 10, 2026, 7:33pm

Hey hey,

I’m redoing my nixos-container to work with mullvad vpn (via services.mullvad), coming from openvpn (protonvpn). I’m running into some trouble getting privateNetwork to work with the container, and it seems like i’m not the only one: (1) (2).

The wiki leads me to believe that my configuration should be enough:

Outside container:

networking = {
    nat = {
      enable = true;
      internalInterfaces = [ "ve-+" ];   # packets coming from ve-* interfaces
      externalInterface = "wg0-mullvad"; # will be translated to VPN thru NAT
    };
    # don't remeber why i had this set, but makes no difference
    # networkmanager.unmanaged = [ "interface-name:ve-*" ];
  };
  <snip>

Inside container:

 containers.pirateship = {
    autoStart = true;
    privateNetwork = true; # needed for vpn
    hostAddress = "192.168.100.10";  # address of the container in pantheon
    localAddress = "192.168.100.11"; # address of pantheon in the container
    <snip>

However,
[root@pirateship:~]# ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 192.168.100.11 icmp_seq=1 Destination Host Unreachable

disabling privateNetwork makes everything connect, and this worked with my earlier openvpn setup.

I don’t know enough about networking to be able to diagnose what’s going wrong, and there seems to be nothing relevant in any logs AFAICT. Anyone know what’s going wrong, or some way to debug this? Any suggestions are welcome

DerDennisOP · May 10, 2026, 8:23pm

You can verify where packets are stuck with tcpdump host 1.1.1.1 and icmp, you can execute this command on every step of your machine (e.g. in the container, and outside of the container, while executing pings in the background). Maybe your Rounting is incorrect. You can verify you rounting by executing ip r get 1.1.1.1 inside the container and see via which interface it is trying to escape your container. Maybe your NAT or Forwarding Rules are broken, by executing the tcpdump commands on the host machine and verifing packages are traveling correctly.

First of all make sure your Firewall rules are correct, since it could be blocked by the firewall. I recommend the pwru utility, that takes tcpdump like instructions.

phaeseeKe5Ee · May 11, 2026, 7:16am

For networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];, it came from nixos manual in the nixos container section.

Not expert here, I also configured nixos-container with wiki’s first block config like yours, but it only let me access services from the host to the containers, but not the other way around.
I tried suggestion from here, but still

I can successfully let container to ping 1.1.1.1 with the bridge setup, also from the nixos wiki, you may try it.
Also I have to explicitly set container localaddress like this in the Additional context to make it work, some thing like this.

github.com/NixOS/nixpkgs

nixos/containers: localAddress blocks gateway configuration (no internet in container)

opened 11:57AM - 12 Apr 26 UTC

closed 08:48PM - 13 Apr 26 UTC

ToppDev

0.kind: bug 6.topic: nixos

### Nixpkgs version - Unstable (26.05) ### Describe the bug When configuring …a container with `containers.<name>.localAddress` and a `containers.<name>.hostBridge`, the default gateway in the container is not set anymore. Therefore resulting in the container to have no internet. ``` $ ping 8.8.8.8 ping: connect: Network is unreachable $ ip route 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11 ``` ### Steps to reproduce **Host config:** ```nix networking = { hostName = "NAS"; hostId = "..."; useDHCP = false; enableIPv6 = false; defaultGateway = "192.168.1.2"; nameservers = [ "192.168.1.2" "8.8.8.8" ]; bridges."br0".interfaces = ["enp1s0"]; interfaces = { "br0".ipv4.addresses = [ { address = "192.168.1.10"; prefixLength = 24; } ]; }; }; ``` **Container config:** ```nix {...}: { containers = { my-container = { autoStart = true; privateNetwork = true; hostBridge = "br0"; localAddress = "192.168.1.11/24"; }; config = {...}: { networking = { enableIPv6 = false; defaultGateway = "192.168.1.2"; nameservers = [ "192.168.1.2" "8.8.8.8" ]; firewall.enable = true; }; }; }; }; } ``` ### Expected behaviour ``` $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=13.1 ms $ ip route default via 192.168.1.2 dev eth0 proto static 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11 192.168.1.2 dev eth0 proto static scope link ``` ### Screenshots _No response_ ### Relevant log output ```console ``` ### Additional context When I unset `containers.<name>.localAddress` and set in the container config ```nix networking.interfaces.eth0.ipv4.addresses = [ { address = "192.168.1.11"; prefixLength = 24; } ]; ``` then it starts working again. I have a weekly update job on my device, so its broken for a week now. So I suspect 1b786dda36c0439763c18651c730caf7dc0ab7e4 ### System metadata - system: `"x86_64-linux"` - host os: `Linux 6.18.21, NixOS, 26.05 (Yarara), 26.05.20260409.4c1018d` - multi-user?: `yes` - sandbox: `yes` - version: `nix-env (Nix) 2.31.4` - channels(root): `"nixos-24.11"` - nixpkgs: `/nix/store/anvdcc2arw7kqrvwnidvhw6ypkkvws68-source` ### Notify maintainers @fpletz --- **Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.) ### I assert that this issue is relevant for Nixpkgs - [x] I assert that this is a bug and not a support request. - [x] I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+label%3A%220.kind%3A+bug%22+label%3A%226.topic%3A+nixos%22). - [x] I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it. ### Is this issue important to you? Add a :+1: [reaction] to [issues you find important]. [reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ [issues you find important]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

networking.interfaces.eth0.ipv4.addresses = [
  {
    address = "192.168.1.11";
    prefixLength = 24;
  }
];

not-jack · May 11, 2026, 9:11am

Hey, thanks for your response!

running
$ sudo tcpdump host 1.1.1.1 and icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

hangs in both the host and container…

jack@pantheon $ ip r get 1.1.1.1

1.1.1.1 dev wg0-mullvad table 1836018789 src 10.150.32.207 uid 1000 
    cache

The following does look weird to me, it looks like 1.1.1.1 gets routed through 192.168.100.10, which is containers.pirateship.hostAddress. I believe that this is the address of the container in the host? Do i need to swap localAddress and hostAddress?

[root@pirateship:~]# ip r get 1.1.1.1

1.1.1.1 via 192.168.100.10 dev eth0 src 192.168.100.11 uid 0 
    cache

should 192.168.100.10 be 192.168.100.11 instead?
[root@pirateship:~]# ping 192.168.100.11

PING 192.168.100.11 (192.168.100.11) 56(84) bytes of data.
64 bytes from 192.168.100.11: icmp_seq=1 ttl=64 time=0.045 ms

this address is reachable.

pwru fails in the container as well
[root@pirateship:~]# pwru

2026/05/11 10:51:16 WARN Failed to retrieve available ftrace functions (is /sys/kernel/tracing or /sys/kernel/debug/tracing mounted?) error="failed to open: open /sys/kernel/debug/tracing/available_filter_functions: no such file or directory"
2026/05/11 10:51:16 ERROR Failed to run pwru error="Cannot find a matching kernel function"

but disabling the firewall in the container makes no difference, so i’m going to assume that’s not the issue here.

not-jack · May 11, 2026, 9:36am

following the bridge setup from the wiki also yields no success.: (full config)

  networking = {
    nat = {
      enable = true;
      internalInterfaces = [ "ve-+" ];   # packets coming from ve-* interfaces
      externalInterface = "wg0-mullvad"; # will be translated to VPN thru NAT
    };
    bridges.br0.interfaces = ["eth0"];
    # Get bridge-ip with DHCP
    useDHCP = false;
    interfaces."br0".useDHCP = true;

    # Set bridge-ip static
    interfaces."br0".ipv4.addresses = [{
      address = "192.168.100.3";
      prefixLength = 24;
    }];
    defaultGateway = "192.168.100.1";
    nameservers = [ "192.168.100.1" ];
  };
  ...
  containers.pirateship = {
    autoStart = true;
    privateNetwork = true; # needed for vpn
    # hostAddress = "192.168.100.10";  # address of the container in pantheon
    hostBridge = "br0";
    localAddress = "192.168.100.5/24"; # address of pantheon in the container
    ...

systemd[1]: Starting Container 'pirateship'...
systemd-nspawn[310040]: ░ Spawning container pirateship on /var/lib/nixos-containers/pirateship.
systemd-nspawn[310040]: Failed to add interface vb-pirateship to bridge br0: No such device
systemd-nspawn[310051]: Parent died too early
systemd[1]: container@pirateship.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: container@pirateship.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Container 'pirateship'.

DerDennisOP · May 11, 2026, 9:44am

It probably hangs because it is trying to resolve your ip addresses via DNS, try sudo tcpdump -ni any host 1.1.1.1 and icmpin the container and on the host. Ping to 192.168.100.11 is your lokalhost and should definitely work.

not-jack · May 11, 2026, 9:50am

edit: does not hang:

[root@pirateship:~]# tcpdump -ni any host 1.1.1.1 and icmp

tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:51:49.053231 eth0  Out IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 37374, seq 1, length 64
11:51:50.098558 eth0  Out IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 37374, seq 2, length 64
11:51:51.123519 eth0  Out IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 37374, seq 3, length 64

DerDennisOP · May 11, 2026, 10:55am

What about your host machine? You can see that Packets are exiting your system but not returning?

not-jack · May 11, 2026, 12:46pm

jack@pantheon $ sudo tcpdump -ni any host 1.1.1.1 and icmp

tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:45:50.734090 wg0-mullvad Out IP 10.132.24.166 > 1.1.1.1: ICMP echo request, id 44815, seq 1, length 64
14:45:50.739612 wg0-mullvad In  IP 1.1.1.1 > 10.132.24.166: ICMP echo reply, id 44815, seq 1, length 64
14:45:51.735515 wg0-mullvad Out IP 10.132.24.166 > 1.1.1.1: ICMP echo request, id 44815, seq 2, length 64
14:45:51.741540 wg0-mullvad In  IP 1.1.1.1 > 10.132.24.166: ICMP echo reply, id 44815, seq 2, length 64
14:45:52.736924 wg0-mullvad Out IP 10.132.24.166 > 1.1.1.1: ICMP echo request, id 44815, seq 3, length 64
14:45:52.742840 wg0-mullvad In  IP 1.1.1.1 > 10.132.24.166: ICMP echo reply, id 44815, seq 3, length 64

those go in and out…

DerDennisOP · May 11, 2026, 1:16pm

but there is nothing when you ping in your container, but execute tcpdump on your host? I would have exepected something like br0 In IP 192.168.100.10 > 1.1.1.1 on your hhost

not-jack · May 11, 2026, 1:23pm

Ah like that, sorry. It was unclear to me where i should run tcpdump. The configuration with bridge br0 fails to launch the container. I’ve reverted back to the original config.

jack@pantheon $ sudo tcpdump -ni any host 1.1.1.1 and icmp

tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
15:21:56.563492 ve-pirateship In  IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 41487, seq 1, length 64
15:21:57.586820 ve-pirateship In  IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 41487, seq 2, length 64
15:21:58.610556 ve-pirateship In  IP 0.0.0.0 > 1.1.1.1: ICMP echo request, id 41487, seq 3, length 64

DerDennisOP · May 12, 2026, 2:05pm

There is definitively something broken with your container config, as the ip is 0.0.0.0 and not like expected 192.168.100.11. Could you do ip a in your container and also on your host machine?

not-jack · May 12, 2026, 2:32pm

host:

jack@pantheon $ ip a                                                                                                                                        ✔  10021  16:26:52 
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
    link/tunnel6 :: brd :: permaddr 12b7:8291:64e9::
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d8:43:ae:65:ff:ee brd ff:ff:ff:ff:ff:ff
    altname enxd843ae65ffee
    inet 192.168.2.234/24 brd 192.168.2.255 scope global dynamic noprefixroute enp5s0
       valid_lft 42272sec preferred_lft 42272sec
    inet6 fe80::1549:bc73:7c42:a3df/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wg0-mullvad: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.159.31.210/32 brd 10.159.31.210 scope global wg0-mullvad
       valid_lft forever preferred_lft forever
    inet6 fc00:bbbb:bbbb:bb01:d:0:1f:1fd2/128 scope global 
       valid_lft forever preferred_lft forever

container:

[root@pirateship:~]# 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
    link/tunnel6 :: brd :: permaddr 228a:7858:2ab3::
3: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:5e:4a:cb:7f:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::d85e:4aff:fecb:7ff7/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

the ip6tnl0 interfaces are new in both machines, could be the result of a flake update?

DerDennisOP · May 12, 2026, 2:36pm

that’s probably one problem, but the eth0 interface is missing a ipv4 address. I expected something like inet 192.168.100.11/24 to see in your eth0 interface.

not-jack · May 12, 2026, 2:41pm

oh damnit, i commented the localAddress. Give me a second to rebuild

not-jack · May 12, 2026, 2:45pm

[root@pirateship:~]# 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
    link/tunnel6 :: brd :: permaddr 4a34:6ce8:bdff::
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:5e:4a:cb:7f:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.100.11/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::d85e:4aff:fecb:7ff7/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

this is the correct one, which does have an ipv4 address attached to the interface

DerDennisOP · May 12, 2026, 2:55pm

and how does tcpdump and ping behave now?

not-jack · May 12, 2026, 3:12pm

tcpdump doesn’t pick up anything on the host while pinging in the container now.

DerDennisOP · May 12, 2026, 3:25pm

it should at least be pick up inside the container.

not-jack · May 12, 2026, 3:32pm

Both inside and outside of the container nothing