Secondary IP not pingable from internet - Ubuntu 20.04 using netplan on Hetzner server

in flag

Let me start be saying I'm not an network expert. That being said, I'd need some help here as I'm breaking my head on this issue for two days now. I have several questions but will focus only on one specific one.

I ordered a hetzner root server and installed Ubuntu 20.04. Right after I ordered a secondary IP as I need it for my docker setup where I want two containers to be accessible directly on these two IP addresses? The IP addresses are both /32 public addresses assigned by Hetzner. My main ip address is accessible from internet, I can ping it from outside.

After requesting the second IP i received a mail from Hetzner that my orde was successful and I can configure my second IP. In the Hetzner docs I read that it should be as easy as adding the second ip address to the addresses portion in /etc/netplan/01-netcfg.yaml. This file looks like this now:

  version: 2
  renderer: networkd
        - on-link: true
          - ...

Right after saving the file I ran netplan try which reported success and hit enter to save the new config. Running ip addr gives me:

2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether a8:a1:22:1f:22:82 brd ff:ff:ff:ff:ff:ff
    inet scope global enp9s0
       valid_lft forever preferred_lft forever
    inet scope global enp9s0
       valid_lft forever preferred_lft forever

Now I can ping the second ip (.199) from the server successfully, but not from the www. Any ideas why this is the case? I want to make sure that my second IP is also accessible from the web. What am I missing in this configuration? Many thanks in advance!

Edit: I am running docker but at this point, everything I stated here is in the host machine. So Docker is not yet involved...

ip -br link gives me:

$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
enp9s0           UP             a8:a1:22:1f:22:82 <BROADCAST,MULTICAST,UP,LOWER_UP> 
docker0          DOWN           02:42:f8:c5:ee:a9 <NO-CARRIER,BROADCAST,MULTICAST,UP>
br-ef57c188e0de  DOWN           02:42:dc:79:c6:f6 <NO-CARRIER,BROADCAST,MULTICAST,UP>


$ ip -4 -br address
lo               UNKNOWN 
enp9s0           UP    
docker0          DOWN 
br-ef57c188e0de  DOWN 


$ ip route
default via dev enp9s0 proto static onlink dev docker0 proto kernel scope link src linkdown dev br-ef57c188e0de proto kernel scope link src linkdown 


$ ip rule
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default


$ ip neigh dev br-ef57c188e0de  FAILED dev enp9s0 lladdr a8:a1:22:1f:22:82 REACHABLE
fe80::1 dev enp9s0 lladdr a8:a1:22:1f:22:82 router STALE

and finally...

$ iptables-save -c
# Generated by iptables-save v1.8.4 on Sat May 14 17:40:11 2022
:INPUT ACCEPT [1021:88276]
:FORWARD DROP [233:12218]
:OUTPUT ACCEPT [920:161517]
:DOCKER - [0:0]
:DOCKER-USER - [0:0]
[12631:643908] -A FORWARD -j DOCKER-USER
[105:5500] -A FORWARD -o br-ef57c188e0de -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -o br-ef57c188e0de -j DOCKER
[6:324] -A FORWARD -i br-ef57c188e0de ! -o br-ef57c188e0de -j ACCEPT
[0:0] -A FORWARD -i br-ef57c188e0de -o br-ef57c188e0de -j ACCEPT
[521962:778892991] -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -o docker0 -j DOCKER
[132612:7158451] -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
[0:0] -A FORWARD -i docker0 -o docker0 -j ACCEPT
[6:324] -A DOCKER-ISOLATION-STAGE-1 -i br-ef57c188e0de ! -o br-ef57c188e0de -j DOCKER-ISOLATION-STAGE-2
[132612:7158451] -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
[686521:790836880] -A DOCKER-ISOLATION-STAGE-1 -j RETURN
[0:0] -A DOCKER-ISOLATION-STAGE-2 -o br-ef57c188e0de -j DROP
[0:0] -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
[132618:7158775] -A DOCKER-ISOLATION-STAGE-2 -j RETURN
[709846:791932195] -A DOCKER-USER -j RETURN
# Completed on Sat May 14 17:40:11 2022
# Generated by iptables-save v1.8.4 on Sat May 14 17:40:11 2022
:INPUT ACCEPT [357:16571]
:DOCKER - [0:0]
[25260:1227195] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
[3:252] -A OUTPUT ! -d -m addrtype --dst-type LOCAL -j DOCKER
[3:180] -A POSTROUTING -s ! -o br-ef57c188e0de -j MASQUERADE
[64:3912] -A POSTROUTING -s ! -o docker0 -j MASQUERADE
[0:0] -A DOCKER -i br-ef57c188e0de -j RETURN
[0:0] -A DOCKER -i docker0 -j RETURN
# Completed on Sat May 14 17:40:11 2022

In addition, I haven't set up any firewall rules yet on Hetzner side either. Thanks for your time!

A.B avatar
cl flag
This should be working (because there's the onlink parameter allowing to have a gateway without LAN route). As it's not you should provide more information: `ip -br link; ip -4 -br address; ip route; ip rule; ip neigh`. Also just in case check firewall rules. So: `iptables-save -c` too. Note: Docker never helps when present to troubleshoot network issues. If you forgot to tell your service was behind Docker, it's time to tell it and describe it: this can matter.
AGI_rev avatar
in flag
I edited the question with the additional info you've asked. Thx for your time ;)
A.B avatar
cl flag
It's supposed to work. You should compare from the server side since it's easier than from remote: `ping` vs `ping -I` and `traceroute -n` vs `traceroute -s`. You could run at the same time something like `traceroute -l -n -s0 -e -p -i enp9s0 arp or icmp` and see if something looks wrong or different between both cases.
in flag

Thanks for your help everyone and especially A.B

Pinging still didn't work. I read all the Hetzner docs and couldn't find any clues until I stumbled upon this post Hetzner additional ip. I had earlier activated the MAC address for the additional IP I've requested because I thought it would be necessary to create a macvlan in docker. I disabled the virtual MAC address in the Hetzner server portal and now I can ping from and to the additional IP. What I haven't figured out yet is described in another post: assigning 32 ip address to docker container. Any help there is more then welcome. Cheers!


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.