[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xense-devel] cannot filter on vif* interfaces using iptables?
Hi, I'd like to use an iptables filter that uses the virtual interface vif for its filtering decision (for example block access to port 80 for a certain domain). My Xen sessions run on a dual ported host that also works as the NAT gateway. eth0: external IP address eth1: internal IP address (10.0.0.1) Xen is setup using bridging, and the xen sessions use ip addresses in the 10.0.1.* range. Everything works fine except that it looks like the kernel does not know the virtual interface a packet comes from anywhere iptables gets a hold of them (if I log the packets I either see eth1 and eth0, or one of the interfaces has no name, I never see vif*). I am using kernel 2.6.16.13-xen0 compiled from the XEN source (latest development branch as of two weeks ago). As suggested by Gerd a few weeks ago I set CONFIG_BRIDGE_NETFILTER=y and CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y but even then the logs just look like this no matter into which table I insert the LOG option: IN=eth1 OUT=eth0 SRC=10.0.1.0 DST=249.115.140.206 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=60085 DF PROTO=TCP SPT=39516 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0 I use the following iptables parameters (I use FC5): *nat :PREROUTING ACCEPT [227:9480] :POSTROUTING ACCEPT [20:6695] :OUTPUT ACCEPT [25:7215] -A POSTROUTING -s 10.0.0.0/16 -d 10.0.0.0/16 -j ACCEPT -A PREROUTING -s 10.0.0.0/16 -d 10.0.0.0/16 -j ACCEPT -A POSTROUTING -o eth0 -s 10.0.0.0/8 -j MASQUERADE COMMIT # Completed on Tue Aug 1 17:27:28 2006 # Generated by iptables-save v1.3.5 on Tue Aug 1 17:27:28 2006 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3216:587050] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT -A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 514 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 123 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 123 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 1027 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 5900:5920 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 5800:5820 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 20000:24999 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 1001 -j ACCEPT -A RH-Firewall-1-INPUT -d 216.224.124.2 -i eth0 -p tcp -m tcp --dport 22000 -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/255.255.0.0 -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/255.255.0.0 -p tcp -m state --state NEW -m tcp --dport 920 -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/255.255.0.0 -p udp -j ACCEPT -A RH-Firewall-1-INPUT -s 10.0.0.0/255.255.0.0 -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT -A RH-Firewall-1-INPUT -d 10.0.1.0/255.255.0.0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Tue Aug 1 17:27:28 2006 # Generated by iptables-save v1.3.5 on Tue Aug 1 17:27:28 2006 Any hints on how to insert a rule that would drop all packets from a certain virtual interface greatly appreciated! I.e. something like -A RH-Firewall-1-INPUT -i vif2.0 --dport 80 -j DROP Thanks, Claudio ---------------------------------------------------------------------------- Claudio Fleiner claudio@xxxxxxxxxxx _______________________________________________ Xense-devel mailing list Xense-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xense-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |