Network Issues

Templates cannot connect to the internet

If your templates cannot connect to the internet or are getting Automatic Private IP Addressing (APIPA) addresses that start with 169.254, your Ludus nat interface may be down or dnsmasq may not be running (or running but not listening).

Before proceeding, try restarting the dnsmasq service on the Ludus server:

systemctl restart dnsmasq

Even if dnsmasq was already running, there have been multiple cases where it was not listening and restarting it fixed the issue.

If that didn't solve your issue, get your ludus_nat_interface value from /opt/ludus/config.yml

root@ludus:~# cat /opt/ludus/config.yml
---
proxmox_node: ludus
proxmox_interface: vmbr0
proxmox_local_ip: 10.98.108.3
proxmox_public_ip: 10.98.108.3
proxmox_gateway: 10.98.108.1
proxmox_netmask: 255.255.255.0
proxmox_vm_storage_pool: local
proxmox_vm_storage_format: qcow2
proxmox_iso_storage_pool: local
ludus_nat_interface: vmbr1000
prevent_user_ansible_add: false

To check if this interface is up, run the following command on the Ludus host:

root@ludus:~# 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: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether bc:24:11:de:d2:b0 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:de:d2:b0 brd ff:ff:ff:ff:ff:ff
    inet 10.98.108.3/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fede:d2b0/64 scope link
       valid_lft forever preferred_lft forever
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 198.51.100.1/24 scope global wg0
       valid_lft forever preferred_lft forever
10: vmbr1000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 82:a4:7a:9a:10:35 brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.254/24 scope global ludus
       valid_lft forever preferred_lft forever
    inet6 fe80::80a4:7aff:fe9a:1035/64 scope link
       valid_lft forever preferred_lft forever
11: vmbr1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:04:2a:a5:84:d0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f804:2aff:fea5:84d0/64 scope link
       valid_lft forever preferred_lft forever

If line 21 (or the line that corresponds with your ludus_nat_interface) shows DOWN inside the angle brackets for the ludus interface, run the following command to bring the interface UP:

ifup vmbr1000

Run ip a again to verify the interface is up. Next, check that the MASQUERADE rule is in place:

root@proxtest:~# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 236 packets, 14443 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 226 packets, 13898 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 328 packets, 22056 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 328 packets, 22056 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  0    --  *      vmbr0   192.0.2.0/24         0.0.0.0/0

Line 13 shows the MASQUERADE rule is in place for the Ludus network range of 192.0.2.0/24. Ludus VMs should now have internet access.

If VMs still are unable to obtain an IP in the 192.0.2.0/24 after this, check the status of the dnsmasq service on the Ludus server.

systemctl status dnsmasq

In some cases, other programs such as conmand listen on port 53 which causes a conflict with dnsmasq. Resolve this conflict and restart dnsmasq. Once dnsmasq is running, VMs should be able to get an IP address via DHCP and access the internet.

For more information about how this all works, learn more about Ludus' networking.

Templates cannot connect to the internet​

Templates cannot connect to the internet