After upgrade from 1.8 to 1.9 the virtual firewall stop working

Pak

New Member
Jun 8, 2010
23
0
1
Verona - Italy
Hi all

I would thank you for Proxmox: it is really great

I have a little issue: after upgrading from 1.8 to 1.9 my virtual firewall (IpCop) stop working well; it means if I reboot it, it works for 10 minutes then the network connection go down

In my IpCop the log is
Sep 13 20:15:15 ipcop kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 13 20:15:15 ipcop kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
Sep 13 20:15:27 ipcop kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 13 20:15:27 ipcop kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
Sep 13 20:15:39 ipcop kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 13 20:15:39 ipcop kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
Sep 13 20:15:47 ipcop dhcpd: receive_packet failed on eth0: Network is down


Some info
in the Proxmox I have 2 physical NIC
In the firewall I have 2 virtual NIC. The one (e1000) bridged to vmbr0 and the other (rtl8139) bridged to vmbr2

All this configuration works well in the 1.8


some configuration:

PROXMOX

ifconfig:
Code:
debborah:~# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:27:0e:24:a7:4d  
          inet6 addr: fe80::227:eff:fe24:a74d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:51592 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40037 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:14804150 (14.1 MiB)  TX bytes:18661850 (17.7 MiB)
          Interrupt:27 

eth2      Link encap:Ethernet  HWaddr 00:23:cd:b6:04:76  
          inet6 addr: fe80::223:cdff:feb6:476/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:149763 errors:0 dropped:0 overruns:0 frame:0
          TX packets:193558 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30090830 (28.6 MiB)  TX bytes:85645446 (81.6 MiB)
          Interrupt:17 Base address:0xc000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:46348 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46348 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:16940773 (16.1 MiB)  TX bytes:16940773 (16.1 MiB)

tap101i2d0 Link encap:Ethernet  HWaddr 2a:33:6b:02:cf:f9  
          inet6 addr: fe80::2833:6bff:fe02:cff9/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:27714 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29599 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:3066917 (2.9 MiB)  TX bytes:4752561 (4.5 MiB)

tap104i0d0 Link encap:Ethernet  HWaddr 1a:4a:d5:c6:87:89  
          inet6 addr: fe80::184a:d5ff:fec6:8789/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1072 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1255 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:159077 (155.3 KiB)  TX bytes:836478 (816.8 KiB)

tap104i2d0 Link encap:Ethernet  HWaddr 5a:b0:8e:f9:47:3a  
          inet6 addr: fe80::58b0:8eff:fef9:473a/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1240 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1487 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:872136 (851.6 KiB)  TX bytes:187858 (183.4 KiB)

tap105i2d0 Link encap:Ethernet  HWaddr fe:74:2d:12:e9:79  
          inet6 addr: fe80::fc74:2dff:fe12:e979/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:15399 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26877 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:805826 (786.9 KiB)  TX bytes:1534717 (1.4 MiB)

tap500i2d0 Link encap:Ethernet  HWaddr ee:0c:e9:54:ed:c7  
          inet6 addr: fe80::ec0c:e9ff:fe54:edc7/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:110404 errors:0 dropped:0 overruns:0 frame:0
          TX packets:146887 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:42143671 (40.1 MiB)  TX bytes:26998699 (25.7 MiB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::1/128 Scope:Link
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vmbr0     Link encap:Ethernet  HWaddr 00:27:0e:24:a7:4d  
          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.xx  Mask:xx.xx.xx.xx
          inet6 addr: fe80::227:eff:fe24:a74d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34378 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22690 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4971440 (4.7 MiB)  TX bytes:14401203 (13.7 MiB)

vmbr2     Link encap:Ethernet  HWaddr 00:23:cd:b6:04:76  
          inet addr:192.168.88.253  Bcast:192.168.88.255  Mask:255.255.255.0
          inet6 addr: fe80::223:cdff:feb6:476/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65631 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44137 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4436157 (4.2 MiB)  TX bytes:35756732 (34.1 MiB)

Hide Public IP for security reasons

Code:
debborah:~# pveversion -v
pve-manager: 1.9-24 (pve-manager/1.9/6542)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-43
pve-kernel-2.6.18-2-pve: 2.6.18-5
pve-kernel-2.6.32-6-pve: 2.6.32-43
qemu-server: 1.1-32
pve-firmware: 1.0-13
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.28-1pve5
vzdump: 1.2-15
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6


I'll try to reinstall the firewall
I'll keep this version cause I like understand what happened

Have a good day

Paolo
 
Last edited:
Almost sure that are driver issues...but I changed nothing in the VM setup during the upgrade.

I'm trying to change the virtual NIC (virtio, ne2k, pcnet...) after the issues, but the only one that works a little bit are rtl8139 and e1000
I know IpCop is little bit old (still using 2.4 kernel) but I'm fond of him



I've installed IpFire for the moment, so I'm not in hurry
 
Hi Pak,
Just to let you know that sharing your vmbr0 IP address (ifconfig printout) in the above reply, give everyone access to your proxmox web interface login page...
Is it correct ?

Shoudn't be behind IpFire and not directly accessible from outside ?

best regards
oban
 
This is correct for the moment... I'll change apache config when everything will be ok

Anyway I hide the IP in the ifconfig

Thank you so much
 
I seize the moment... I did this configuration because I haven't find out how to set the public IP only in the virtual firewall, without setting another valid IP in the Proxmox physical interface... did I miss something?
 
I have the same approach...

let me share my own experience with IpFire (works also with Microsoft forefront TMG). In the Proxmox web interface I have set 2 bridges, namely vmbr0 for the local network area and vmbr1 for the public network (internet). In my case, my internet provider give me a range of 8 IPs (if I remember well your ifconfig :)... , your netmask was 255.255.255.248 and let me think that you should have also 8 public IP availables.

Let say that the range of public IP is 222.222.222.57 to 222.222.222.62 (222.222.222.56 & 222.222.222.63 not usable). I have set the vmbr1 bridge to 222.222.222.60. In IpFire I have set IP address of the red interface with the real public address published in my DNS provider, let say 222.222.222.59.

My configuration is build with 2 Server in cluster. In order to have the live migration still working for a VM running a firewall, I have configured in the same way the 2nd computer. But the vmbr1 bridge own another address of the range of 8 public IP, let say 222.222.222.61.

It works like a charm. The only drawback is the use of one public IP address per server added in the cluster for the vmbr1 bridge.

I don't see any other way to do it.

oban
 
You're right, I have 8 public IPs and I've done exactly as you say...

The only way I found to "not publish" the Proxmox server interface in internet was to change the apache configuration

In the past I used vmware server (1.0 and 2.0) and in those server was possibile to bridge a virtual nic to a physical nic. If you set the IP only in the virtual interface and leave the physical one without IP, they works too.
In proxmox I can't do it

But I don't wanna miss the tread subject.

Pak
 
OK.

I don't understand in your case why the Proxmox web interface is accessible from your public IP. In my configuration the Proxmox web interface can be reached only by using the Proxmox master IP address which is in the local area network. There is no reason to have it visible outside excepted if you have added a rule in IPFire that redirected the http port 80 to the master IP address. (in IPFire -> port forwarding).

If you have any web server to publish, you should use the IPFire port forwarding rule to redirect your http 80 to this web server.


oban
 
Because I configure the vmbr0 as WAN interface and vmbr2 as LAN

I configure in this way because i can use the proxmox gateway... Am I wrong?

I attach a network schema... let me know if you think there is some errors
View attachment network.pdf
As you can see, the proxmox physical interface is between the router and the firewall, so I don't think is not possibile to protect him with the firewall

Pak

PS
Please, don't comment the beauty of my work :)
 
Last edited:
Your drawing is very clear and correspond to my topology. And Oh! surprise, the same issue :)... the web interface is accessible also on each bridge IP address on the external network. I didn't see.
it is probably necessary to play with apache to filter this. In the meantime, if you find the correct apache modification, I will be happy to apply it !

oban
 
I think is possible to block external web connection in 2 ways:

-- APACHE --
HOPE SOMEONE CONFIRM WHAT I'LL WROTE
I'm not Apache guru

Edit /etc/apache2/sites-enabled/pve.conf
Replace <VirtualHost *:80> and <VirtualHost *:443> with <VirtualHost YOURLANIP:80> and <VirtualHost YOURLANIP:443>
Then restart apache


-- IPTABLES --
put something similar in some startup script like /etc/rc.local
(vmbr0 is the WAN interface)
iptables -A INPUT -i vmbr0 -p tcp --dport 80 -J DROP
iptables -A INPUT -i vmbr0 -p tcp --dport 443 -J DROP

If I'm correct, this block the request to port 80 and 443 direct to ProxMox, but not the request for some internal web server...

Just test it :)

Obviusly we're talking only about web interface
For other security issues (like ssh) you must proceed in other way
(#ListenAddress 0.0.0.0 in the /etc/ssh/sshd_config file or adding another iptables line like
iptables -A INPUT -i vmbr0 -p tcp --dport 22 -J DROP )

Pak
 
I have tried to replace the <Virtualhost *:80> & <VirtualHost *:443> with your suggested modification but without success. However I found another way. I have modified the file /etc/apache2/ports.conf by
adding the Proxmox node IP address to the "Listen" parameter.

before modification:

Listen 80
Listen 443

after modification:

Listen aaa.bbb.ccc.ddd:80
Listen aaa.bbb.ccc.ddd:443

In my cluster I have applied the modification to both Proxmox nodes.

Your suggested sshd_config modification works as well.


Thanks !
oban
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!