>>Ok,I understand, I'll test it today Damn, you are right, if the outgoinf rules of first tap interface exist, the ingoing rules for second tap in not processed.
in this example, tap110i0 is allow to ssh out , and tap115i0 drop all incomming packets. If I connect from external network to tap115i0, it's blocked. If i connect from tap110i0 to tap115i0, is allowed.... If I remove the firewall for --physdev-in tap110i0 -j tap110i0-out (so full open out),the incoming rules from tap115i0 is processed, and it's blocked I think that why openstack/ec2 only define incoming rules. It's not a security problem for internal vm traffic (as you can manage incoming rules), But I don't known how to block external traffic to internet ? Maybe an incoming rule on physical interface ? iptables -A eth0 -p tcp --dport 80 --src macaddressoftaop110i0 -j ACCEPT I'm looking at cloudstack, because they use outgoing and incoming rules https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=scripts/vm/network/security_group.py;h=1bcbc3e10fcdd076fb862e00b1271863570935b9 But they also use bridge in rules. Maybe does it work if tap interfaces are on differents bridge ? (I'll test) If yes, could be tricky, but create 1bridge by tap interface could work ? tap110i0---vmbr0tap110i0-------vmbr0-----vmbr0tap115i0-------tap115i0 sample test: ----------- iptables -F iptables -X iptables -N tap110i0-out iptables -N tap110i0-in #out iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in tap110i0 -j tap110i0-out #in iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-out tap110i0 -j tap110i0-in iptables -N tap115i0-out iptables -N tap115i0-in #out iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in tap115i0 -j tap115i0-out #in iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-out tap115i0 -j tap115i0-in #out rules for tap110i0 : allow out ssh iptables -A tap110i0-out -p tcp --dport 22 -j ACCEPT iptables -A tap110i0-out -j LOG --log-prefix "tap110out-dropped: " --log-level 4 iptables -A tap110i0-out -j DROP #in rules for tap110i0 iptables -A tap110i0-in -m state --state INVALID -j DROP iptables -A tap110i0-in -m state --state RELATED,ESTABLISHED -j RETURN iptables -A tap110i0-in -j LOG --log-prefix "tap110i0in-dropped: " --log-level 4 iptables -A tap110i0-in -j DROP #out rules for tap115i0 iptables -A tap115i0-out -j ACCEPT #in rules for tap115i0 (drop all) iptables -A tap115i0-in -m state --state INVALID -j DROP iptables -A tap115i0-in -m state --state RELATED,ESTABLISHED -j RETURN iptables -A tap115i0-in -j LOG --log-prefix "tap11i5in-dropped: " --log-level 4 iptables -A tap115i0-in -j DROP ----- Mail original ----- De: "Alexandre DERUMIER" <aderum...@odiso.com> À: "Dietmar Maurer" <diet...@proxmox.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Mercredi 22 Janvier 2014 09:19:05 Objet: Re: [pve-devel] RFC : iptables implementation >>If you trigger an 'ACCEPT' inside the 'tap110i0-out' chain, the input >>chain 'tap120i0-in' is never processed? Ok,I understand, I'll test it today ----- Mail original ----- De: "Dietmar Maurer" <diet...@proxmox.com> À: "Alexandre DERUMIER" <aderum...@odiso.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Mercredi 22 Janvier 2014 08:19:02 Objet: RE: [pve-devel] RFC : iptables implementation > -----Original Message----- > From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel- > boun...@pve.proxmox.com] On Behalf Of Dietmar Maurer > Sent: Mittwoch, 22. Jänner 2014 08:13 > To: Alexandre DERUMIER > Cc: pve-devel > Subject: Re: [pve-devel] RFC : iptables implementation > > > >>I am not sure if that model correctly handle traffic form one VM to > > >>another > > (traffic from VM1 to VM2)? > > >>Because you would need to apply out rules for VM1, the in rules for VM2. > > >>Does that work - if so how? > > > > Well, is like to have 2vms behind 2 firewalls. > > OK, so I just believe you that this will work ;-) (I just wonder why > shorewall need > those forwarding chains if it work without) for example: --------------- #out iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in tap110i0 -j tap110i0-out #in iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-out tap120i0 -j tap120i0-in ------------ If you trigger an 'ACCEPT' inside the 'tap110i0-out' chain, the input chain 'tap120i0-in' is never processed? _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
