Hello,
I am trying to configure a virtualized PVE host (VMware) with two virtual network cards connected to a firewall (Palo Alto).
I do not have access to the VMware level or the Palo Alto configuration (private cloud provider).
The goal is to deploy certain CTs on the PVE and a Proxmox Backup Server virtual machine so that we can back up and restore the CTs on demand.
The first CT I need to deploy is an Nginx Proxy Manager in a Palo Alto DMZ zone.
The PVE host configuration is linked to a Linux bridge (vmbr0 linked to ens122 provided by VMware virtualization) on which I have assigned a fixed IP address for managing and configuring CTs in the local network.
I created a second Linux bridge (vmbr1 linked to ens224 provided by VMware virtualization) on which I only configure the link with ens244 to dedicate the network card (in the Palo Alto DMZ) to the NPM container.
auto lo
iface lo inet loopback
auto ens192
iface ens192 inet manual
auto ens224
iface ens224 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.1X1.2X2.141/25
gateway 10.1X1.2X2.129
bridge-ports ens192
bridge-stp off
bridge-fd 0
auto vmbr1
iface vmbr1 inet manual
bridge-ports ens224
bridge-stp off
bridge-fd 0
#DMZ
When I configure the NPM CT, I assign it the IP address provided for the DMZ zone.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.1X1.2X2.5/25
gateway 10.1X1.2X2.1
The problem encountered is that the CT does not communicate with the DMZ zone gateway.
I ran some captures and came to the following conclusions:
root@PVE01:~# tcpdump -i vmbr1 -n -e arp or icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:38:31.037149 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 1, length 64
12:38:32.056486 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 2, length 64
12:38:33.080520 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 3, length 64
12:38:34.104523 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 4, length 64
12:38:36.216446 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:37.240446 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:38.264458 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:41.201292 00:50:56:98:c4:36 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1X1.2X2.5 (ff:ff:ff:ff:ff:ff) tell 10.1X1.2X2.1, length 46
12:38:41.201334 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Reply 10.1X1.2X2.5 is-at bc:24:11:ef:e0:97, length 28
12:38:42.378057 00:50:56:98:c4:36 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1X1.2X2.5 (ff:ff:ff:ff:ff:ff) tell 10.1X1.2X2.1, length 46
12:38:42.378098 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Reply 10.1X1.2X2.5 is-at bc:24:11:ef:e0:97, length 28
root@PVE01:~# tcpdump -i ens224 -n -e arp or icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens224, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:39:19.400548 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 1, length 64
12:39:20.440527 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 2, length 64
12:39:21.464525 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 3, length 64
12:39:22.488524 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 4, length 64
12:39:24.856493 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:39:25.880471 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:39:26.904491 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
- No ARP or ICMP response received when the virtual network card is used by the CT.
- Tests with the provider's network team confirm that the gateway responds when vmbr1 has an IP (10.1X1.2X2.5/25), which validates the network path outside the CT.
- The internal bridging (CT ↔ vmbr1 ↔ ens224) works.
I don't have enough experience with Proxmox VE to say for sure that the configuration is correct and that the problem is more likely to be located at the provider's virtualization layer.
So, first and foremost, I would like to know if anyone has had a similar experience to share.
Thank you.
I am trying to configure a virtualized PVE host (VMware) with two virtual network cards connected to a firewall (Palo Alto).
I do not have access to the VMware level or the Palo Alto configuration (private cloud provider).
The goal is to deploy certain CTs on the PVE and a Proxmox Backup Server virtual machine so that we can back up and restore the CTs on demand.
The first CT I need to deploy is an Nginx Proxy Manager in a Palo Alto DMZ zone.
The PVE host configuration is linked to a Linux bridge (vmbr0 linked to ens122 provided by VMware virtualization) on which I have assigned a fixed IP address for managing and configuring CTs in the local network.
I created a second Linux bridge (vmbr1 linked to ens224 provided by VMware virtualization) on which I only configure the link with ens244 to dedicate the network card (in the Palo Alto DMZ) to the NPM container.
auto lo
iface lo inet loopback
auto ens192
iface ens192 inet manual
auto ens224
iface ens224 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.1X1.2X2.141/25
gateway 10.1X1.2X2.129
bridge-ports ens192
bridge-stp off
bridge-fd 0
auto vmbr1
iface vmbr1 inet manual
bridge-ports ens224
bridge-stp off
bridge-fd 0
#DMZ
When I configure the NPM CT, I assign it the IP address provided for the DMZ zone.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.1X1.2X2.5/25
gateway 10.1X1.2X2.1
The problem encountered is that the CT does not communicate with the DMZ zone gateway.
I ran some captures and came to the following conclusions:
root@PVE01:~# tcpdump -i vmbr1 -n -e arp or icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:38:31.037149 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 1, length 64
12:38:32.056486 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 2, length 64
12:38:33.080520 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 3, length 64
12:38:34.104523 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 10376, seq 4, length 64
12:38:36.216446 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:37.240446 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:38.264458 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:38:41.201292 00:50:56:98:c4:36 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1X1.2X2.5 (ff:ff:ff:ff:ff:ff) tell 10.1X1.2X2.1, length 46
12:38:41.201334 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Reply 10.1X1.2X2.5 is-at bc:24:11:ef:e0:97, length 28
12:38:42.378057 00:50:56:98:c4:36 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1X1.2X2.5 (ff:ff:ff:ff:ff:ff) tell 10.1X1.2X2.1, length 46
12:38:42.378098 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Reply 10.1X1.2X2.5 is-at bc:24:11:ef:e0:97, length 28
root@PVE01:~# tcpdump -i ens224 -n -e arp or icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens224, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:39:19.400548 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 1, length 64
12:39:20.440527 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 2, length 64
12:39:21.464525 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 3, length 64
12:39:22.488524 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype IPv4 (0x0800), length 98: 10.1X1.2X2.5 > 10.1X1.2X2.1: ICMP echo request, id 50010, seq 4, length 64
12:39:24.856493 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:39:25.880471 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
12:39:26.904491 bc:24:11:ef:e0:97 > 00:50:56:98:c4:36, ethertype ARP (0x0806), length 42: Request who-has 10.1X1.2X2.1 tell 10.1X1.2X2.5, length 28
- No ARP or ICMP response received when the virtual network card is used by the CT.
- Tests with the provider's network team confirm that the gateway responds when vmbr1 has an IP (10.1X1.2X2.5/25), which validates the network path outside the CT.
- The internal bridging (CT ↔ vmbr1 ↔ ens224) works.
I don't have enough experience with Proxmox VE to say for sure that the configuration is correct and that the problem is more likely to be located at the provider's virtualization layer.
So, first and foremost, I would like to know if anyone has had a similar experience to share.
Thank you.
