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 actually do:> iptables "$c" FORWARD -m physdev --physdev-in "$vif" "$@" -j ACCEPT \ > 2>/dev/null && > iptables "$c" FORWARD -m state --state RELATED,ESTABLISHED -m physdev > \ > --physdev-out "$vif" -j ACCEPT 2>/dev/null>From what i can tell the goal of these lines is to allow networking evenif the default FORWARD policy is DENY, am I right? Is there any additional side-effect if I comment these lines out in vim-common.sh, that I''m not considering? Thanks, D. -- Dmitry Nedospasov <dmitry@nedos.net> -- Twitter: @nedos Web: http://nedos.net -- Github: http://github.com/nedos _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Dmitry, Dmitry Nedospasov wrote:> 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 actually do: > >> iptables "$c" FORWARD -m physdev --physdev-in "$vif" "$@" -j ACCEPT \ >> 2>/dev/null && >> iptables "$c" FORWARD -m state --state RELATED,ESTABLISHED -m physdev >> \ >> --physdev-out "$vif" -j ACCEPT 2>/dev/null > >>From what i can tell the goal of these lines is to allow networking even > if the default FORWARD policy is DENY, am I right? Is there any > additional side-effect if I comment these lines out in vim-common.sh, > that I''m not considering?That caused me issues and those settings were in place due to "anti-spoofing" setup. I dropped anti-spoofing to "fix" my setup somewhat. Until I did that, I couldn''t get to the DomU machines directly via the bridged interface. Now I can get through, but there are still issues that are not resolved [1] -- sometimes I connect, sometimes I don''t; I really need a fix for this. [1] http://comments.gmane.org/gmane.comp.emulators.xen.user/66214 -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Apr 26, 2011 at 8:19 PM, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:> Hi Dmitry, > > Dmitry Nedospasov wrote: >> >> 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 actually do: >> >>> iptables "$c" FORWARD -m physdev --physdev-in "$vif" "$@" -j ACCEPT \ >>> 2>/dev/null && >>> iptables "$c" FORWARD -m state --state RELATED,ESTABLISHED -m physdev >>> \ >>> --physdev-out "$vif" -j ACCEPT 2>/dev/null >> >>> From what i can tell the goal of these lines is to allow networking even >> >> if the default FORWARD policy is DENY, am I right? Is there any >> additional side-effect if I comment these lines out in vim-common.sh, >> that I''m not considering? > > That caused me issues and those settings were in place due to > "anti-spoofing" setup. > > I dropped anti-spoofing to "fix" my setup somewhat. Until I did that, I > couldn''t get to the DomU machines directly via the bridged interface. > > Now I can get through, but there are still issues that are not resolved [1] > -- sometimes I connect, sometimes I don''t; I really need a fix for this. > > > [1] http://comments.gmane.org/gmane.comp.emulators.xen.user/66214 >Are you looking for a patch to support anti-spoof feature for tap devices? If so, which xen version you are looking for? I have patches to support tap devices when anti-spoof feature is enabled. Thanks. Kindest regards, Giam Teck Choon P.S. Sorry, previous mail I forgot to click "Reply-All" :( _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Teck, Teck Choon Giam wrote:> On Tue, Apr 26, 2011 at 8:19 PM, Andrew McGlashan >> That caused me issues and those settings were in place due to >> "anti-spoofing" setup. >> >> I dropped anti-spoofing to "fix" my setup somewhat. Until I did that, I >> couldn''t get to the DomU machines directly via the bridged interface. >> >> Now I can get through, but there are still issues that are not resolved [1] >> -- sometimes I connect, sometimes I don''t; I really need a fix for this. >> >> [1] http://comments.gmane.org/gmane.comp.emulators.xen.user/66214 >> > > Are you looking for a patch to support anti-spoof feature for tap > devices? If so, which xen version you are looking for? I have > patches to support tap devices when anti-spoof feature is enabled.Perhaps, do you think that will help in this situation? # cat /etc/debian_version 6.0.1 # dpkg-query -l|grep xen|awk ''{print $1,$2,$3}'' ii libxenstore3.0 4.0.1-2 ii linux-image-2.6.32-5-xen-amd64 2.6.32-31 ii xen-hypervisor-4.0-amd64 4.0.1-2 ii xen-tools 4.2-1 ii xen-utils-4.0 4.0.1-2 ii xen-utils-common 4.0.0-1 ii xenstore-utils 4.0.1-2 How would the patch be implemented? Thanks. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Apr 27, 2011 at 10:56 AM, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:> Hi Teck, > > Teck Choon Giam wrote: >> >> On Tue, Apr 26, 2011 at 8:19 PM, Andrew McGlashan >>> >>> That caused me issues and those settings were in place due to >>> "anti-spoofing" setup. >>> >>> I dropped anti-spoofing to "fix" my setup somewhat. Until I did that, I >>> couldn''t get to the DomU machines directly via the bridged interface. >>> >>> Now I can get through, but there are still issues that are not resolved >>> [1] >>> -- sometimes I connect, sometimes I don''t; I really need a fix for this. >>> >>> [1] http://comments.gmane.org/gmane.comp.emulators.xen.user/66214 >>> >> >> Are you looking for a patch to support anti-spoof feature for tap >> devices? If so, which xen version you are looking for? I have >> patches to support tap devices when anti-spoof feature is enabled. > > Perhaps, do you think that will help in this situation? > > # cat /etc/debian_version > 6.0.1 > > > # dpkg-query -l|grep xen|awk ''{print $1,$2,$3}'' > ii libxenstore3.0 4.0.1-2 > ii linux-image-2.6.32-5-xen-amd64 2.6.32-31 > ii xen-hypervisor-4.0-amd64 4.0.1-2 > ii xen-tools 4.2-1 > ii xen-utils-4.0 4.0.1-2 > ii xen-utils-common 4.0.0-1 > ii xenstore-utils 4.0.1-2 > > > How would the patch be implemented? > > Thanks. > > -- > Kind Regards > AndrewM > > Andrew McGlashan > Broadband Solutions now including VoIP > >Sorry, I don''t use debian and my patch are against the source. I assume you are using xen-4.0. The following patch should apply cleanly for xen-4.0 if not let me know: diff -urN a/tools/hotplug/Linux/network-bridge b/tools/hotplug/Linux/network-bridge --- a/tools/hotplug/Linux/network-bridge 2010-12-18 01:57:33.000000000 +0800 +++ b/tools/hotplug/Linux/network-bridge 2010-12-18 07:42:29.000000000 +0800 @@ -188,11 +188,23 @@ # Set the default forwarding policy for $dev to drop. # Allow forwarding to the bridge. antispoofing () { - iptables -P FORWARD DROP - iptables -F FORWARD + local isforwardpolicydrop=`iptables -L FORWARD |grep policy|grep DROP|grep -v grep` + if [ "x$isforwardpolicydrop" == "x" ] ; then + iptables -P FORWARD DROP + iptables -F FORWARD + fi iptables -A FORWARD -m physdev --physdev-in ${pdev} -j ACCEPT } +# Set the default forwarding policy for $dev to accept +disable_antispoofing () { + local isforwardpolicydrop=`iptables -L FORWARD |grep policy|grep DROP|grep -v grep` + if [ "x$isforwardpolicydrop" != "x" ] ; then + iptables -P FORWARD ACCEPT + iptables -F FORWARD + fi +} + # Usage: show_status dev bridge # Print ifconfig and routes. show_status () { @@ -283,6 +295,10 @@ brctl delbr ${tdev} + if [ ${antispoof} = ''yes'' ] ; then + disable_antispoofing + fi + release_lock "network-bridge" } diff -urN a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh --- a/tools/hotplug/Linux/vif-common.sh 2010-12-18 01:57:33.000000000 +0800 +++ b/tools/hotplug/Linux/vif-common.sh 2010-12-18 07:46:01.000000000 +0800 @@ -63,12 +63,33 @@ vif="$vifname" fi +pre_frob_iptable_delay() +{ + local tapif=`echo $vif | sed ''s/vif/tap/''` + # for xm create + local checktapif=`cat /proc/net/dev | grep "${tapif}:" | grep -v grep` + + if [ ! -n "$checktapif" ] ; then + # Implement ${MYTAPDELAY} environment variable for delay in seconds sleep to wait + # for brctl add tap devices as sometimes tap devices not being up on time. + # default is 3 seconds + # Such environment set in /etc/xen/scripts/hotplugpath.sh + if [ ! -n "$MYTAPDELAY" ] ; then + MYTAPDELAY=3 + else + # Necessary in order to make sure it is in numberic + MYTAPDELAY=`echo "$MYTAPDELAY" | bc` + fi + sleep ${MYTAPDELAY} + fi +} frob_iptable() { if [ "$command" == "online" ] then local c="-I" + pre_frob_iptable_delay else local c="-D" fi @@ -78,6 +99,24 @@ iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-out "$vif" \ -j ACCEPT 2>/dev/null + # Added support for tap network devices in iptables FORWARD chain as this + # is required if antispoof is enabled or otherwise all packets to/from tap + # devices will be dropped. + # Start adding by Giam Teck Choon. + local tapif=`echo $vif | sed ''s/vif/tap/''` + # for xm create + local checktapif=`cat /proc/net/dev | grep "${tapif}:" | grep -v grep` + # for xm shutdown + local checktapstate=`iptables -L -n | grep "state RELATED,ESTABLISHED PHYSDEV match --physdev-out ${tapif}"` + + if [ -n "$checktapif" ] || [ -n "$checktapstate" ] ; then + iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-in \ + "$tapif" "$@" -j ACCEPT 2>/dev/null && + iptables "$c" FORWARD -m state --state RELATED,ESTABLISHED -m physdev \ + --physdev-is-bridged --physdev-out "$tapif" -j ACCEPT 2>/dev/null + fi + # End adding by Giam Teck Choon. + if [ "$command" == "online" -a $? -ne 0 ] then log err "iptables setup failed. This may affect guest networking." @@ -114,7 +153,10 @@ done # Always allow the domain to talk to a DHCP server. - frob_iptable -p udp --sport 68 --dport 67 + # Such environment set in /etc/xen/scripts/hotplugpath.sh + if [ ! -n ${MYDHCPDISABLE} ] ; then + frob_iptable -p udp --sport 68 --dport 67 + fi else # No IP addresses have been specified, so allow anything. frob_iptable _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, Apr 28, 2011 at 12:22 PM, Teck Choon Giam <giamteckchoon@gmail.com> wrote:> On Wed, Apr 27, 2011 at 10:56 AM, Andrew McGlashan > <andrew.mcglashan@affinityvision.com.au> wrote: >> Hi Teck, >> >> Teck Choon Giam wrote: >>> >>> On Tue, Apr 26, 2011 at 8:19 PM, Andrew McGlashan >>>> >>>> That caused me issues and those settings were in place due to >>>> "anti-spoofing" setup. >>>> >>>> I dropped anti-spoofing to "fix" my setup somewhat. Until I did that, I >>>> couldn''t get to the DomU machines directly via the bridged interface. >>>> >>>> Now I can get through, but there are still issues that are not resolved >>>> [1] >>>> -- sometimes I connect, sometimes I don''t; I really need a fix for this. >>>> >>>> [1] http://comments.gmane.org/gmane.comp.emulators.xen.user/66214 >>>> >>> >>> Are you looking for a patch to support anti-spoof feature for tap >>> devices? If so, which xen version you are looking for? I have >>> patches to support tap devices when anti-spoof feature is enabled. >> >> Perhaps, do you think that will help in this situation? >> >> # cat /etc/debian_version >> 6.0.1 >> >> >> # dpkg-query -l|grep xen|awk ''{print $1,$2,$3}'' >> ii libxenstore3.0 4.0.1-2 >> ii linux-image-2.6.32-5-xen-amd64 2.6.32-31 >> ii xen-hypervisor-4.0-amd64 4.0.1-2 >> ii xen-tools 4.2-1 >> ii xen-utils-4.0 4.0.1-2 >> ii xen-utils-common 4.0.0-1 >> ii xenstore-utils 4.0.1-2 >> >> >> How would the patch be implemented? >> >> Thanks. >> >> -- >> Kind Regards >> AndrewM >> >> Andrew McGlashan >> Broadband Solutions now including VoIPOops... sorry didn''t read the link you provided earlier on. You may ignore the patch I posted as that is for tap devices with antispoofing enabled. Perhaps you want to post your dom0 network configuration?>From the linked posts, you seems like using xen provided networkconfiguration instead of using vendor provided network configuration? Have you look at the following? http://wiki.debian.org/Xen#Dom0_.28host.29 Especially http://wiki.debian.org/BridgeNetworkConnections Hope this helps. Thanks. Kindest regards, Giam Teck Choon _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Teck Choon Giam wrote:> On Thu, Apr 28, 2011 at 12:22 PM, Teck Choon Giam > http://wiki.debian.org/Xen#Dom0_.28host.29 > Especially http://wiki.debian.org/BridgeNetworkConnectionsI''ve been through both those links and cant'' see anything that will help my situation. I did try turning on spanning tree protocol, but it didn''t make any difference, so I turned it off again [it seemed a long shot anyway]. brctl stp eth0 on brctl stp eth1 on> Hope this helps.No, but thank you very much for your efforts. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Seemingly Similar Threads
- compiling kernel in Centos Domu
- XEN 4.1.2+Centos 6.2+Kernel 3.X
- XEN 4.1.2+Centos 6.2+Kernel 3.X
- $MAIL environment variable to override mail_location works in v1.2.16 but not in v2.0.7 for /usr/libexec/dovecot/imap
- FATAL PAGE FAULT - xen-3.0.5-rc2 and xen-3.0.5-rc3