similar to: Bug#613540: xen-utils-common: iptables rules missing for qemu tap interfaces

Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),

Package: xen-utils-common Version: 4.1.3-8 Severity: important When antispoof is set to 'on', the vif-common script does not create an ALLOW firewall rule for the emulated vif devices. This means that HVM nodes, unless a Xen PV driver is installed and running, cannot access the external network. The vif-common script creates an ACCEPT entry for the normal vif device (e.g. vif4.0) but not

Hey everyone, I have a question about vif-common.sh. I run multiple bridges attached on dummy interfaces, which allow me to put guests in seperate subnets (routed through the dom0). As you might expect I already have quite extensive iptables scripts to accomidate this kind of routing. I was just hoping someone on this list can confirm, that I understand what the iptables lines in vif-common.sh

Hi, I contact you as i have difficulties to use nwfilter with KVM host. I want to implemente flow filtering between my Linux guests. I created the following filter : cat admin-dmz-internet.xml <filter name='admin-dmz-internet'> <!-- this zone is an SSH ingoing only zone --> <!-- but SSH can go to an other SSH proxy --> <filterref

This patch adds an ACM hook into the network scripts (/etc/xen/scripts). It adds iptables rules that enforce mandatory access control on network packets exchanged between virtual interfaces. If ACM is active, this patch sets the default FORWARD policy in Dom0 to DROP and adds iptables ACCEPT rules between vifs that belong to domains that are permitted to share (determined by using the

Hi, I''ve been making leaps and strides with Xen on FC4. It has been easy to get installed and to start our first virtual host. I''ve got one outstanding issue with iptables that is preventing me progressing further. This is a colo''d server. It has s single NIC with public IPs. The bridge is set to come up binding vif* <> xen-br0 <> eth1. I can start a

I recently encountered this in the logs of a new Debian Xen Dom0, and having now spent the better part of a day researching and testing, I've come to the conclusion that this is not a bug in xen-utils-common or even iptables; it's merely the consequence of structural changes to the core netfilter code starting in the 2.6.20 kernel. This is rather long, but the issue is complicated. Please

Package: xen-utils-common Version: 3.4.2-3 --- Please enter the report below this line. --- After several tests and many hours of investigation I found out that this is not a bug. The iptables rules that triggers the message is found in /etc/xen/scripts/vif-common.sh [1], but as the syslog message clearly indicates this rule works perfectly when the traffic is bridged. Moreover, those rules are

Hi, I''ve been making leaps and strides with Xen on FC4. It has been easy to get installed and to start our first virtual host. I''ve got one outstanding issue with iptables that is preventing me progressing further. This is a colo''d server. It has s single NIC with public IPs. The bridge is set to come up binding vif* <> xen-br0 <> eth1. I can start a

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal I cannot find a use the network-nat and vif-nat provided in the general case, where I'd like to NAT between vifx.0 and ethx interfaces. I have setup the following in /etc/xen/xend-config.sxp : ## Use the following if network traffic is routed with NAT, as an alternative # to the settings for bridged networking given above.

Hi folks, I am trying to get antispoofing running on xen3 (based on Debian Sarge). This is what I have done to enable it: 1. I have compiled a dom0 kernel with CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m 2. I made sure this module is loaded: lsmod gives xt_physdev (among others). 3a. I have changed the line "(network-script network-bridge)" to "(network-script network-bridge

Package: xen-utils-common Version: 3.4.2-2 Severity: important The network setup uses not longer supported iptables operations: | physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate

Hello with XEN 3.4.x antispoof=yes works on a bridge setup. I am using this line in xend-config.sxp (network-script ''network-bridge antispoof=yes'') It creates this under IPTABLES FORWARD chain: ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in peth0 Under XEN 4.0.1 it is not working, it does not create a IPTABLES rule. Customers can

Package: xen-utils-common Version: 4.0.0-1 Severity: important The script /etc/xen/scripts/block contains an error in the part which is checking the sharing of the already created loop devices. This error leads in the case of somespecific file inode values to the wrong report of the loop device as being already used and causes then the domain could not be started with such device at all, there

Package: xen-utils-common Version: 4.0.0-1 Severity: normal A strange issue, when deploying Xen using Puppet, /etc/udev/rules.d/xend.rules and /etc/udev/rules.d/xen-backend.rules files are empty. Specifically, the symlinks point to ../xend.rules and ../xen-backend.rules respectively in /etc/udev, but neither of those files exist. Manually copying those files from another host that was not

Package: xen-utils-common Followup-For: Bug #430778 Here's a patch I made to have working rules here... feel free to comment/adapt. Hope this helps -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-xen-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8,

Hi all, I have Xen 3.2 newly installed on Lenny with network bridging configured. When I built my first VM, I found it couldn''t connect to the Internet. This turned out to be because my dom0''s iptables was configured to DROP all packets on the FORWARD chain (when I removed that, it started working). The "Xen Networking" page on the wiki describes this exact situation

Hello, What is the best policy for the FORWARD chain in dom0 iptables? Can I use a default DROP policy? I notice when domains are created it adds the extra rules to the FORWARD chain, to allow traffic to the guests. However, if iptables is restarted, all these rules are lost. Do I need a rule per VPS, or can I use a single catch all to handle all of them?

Package: xen-utils-common Version: 4.0.0-1 Severity: normal Tags: squeeze The host runs (at the time of testing) a single linux-x86 domu (128MB, 1VCPU). When issuing a reboot, everything looks as expected: - domu is saved - xend is stopped - drbd stopped - lvms unmounted - md0..4 stopped and the message "rebooting now" appears, but nothing happens until "INFO: task xenwatch is

Package: xen-utils-common Version: 4.0.0-1 Severity: important If using ethernet bonding and network-bridge with xen the network-bridge scripts breaks the network. I have run through the commands manually in irder to establish the culprit. In the op_start function (Starting on line 214) everything is fine up until line 251. At this point the bridge has been created, devices renamed and the