[pve-devel] RFC : iptables implementation

Wed Jan 22 10:27:06 CET 2014

Hi, again,
It's seem to works if I use RETURN instead ACCEPT in outgoing rules.
(to another tap, or to external network).

cloudstack seem to use similar setup,but directly on the chain. (I need to look how they build the chains)

execute("iptables -A " + brfw + "-OUT" +  " -m physdev --physdev-is-bridged --physdev-out " + vif +  " -j " + vmchain)
execute("iptables -A " + brfw + "-IN" + " -m physdev --physdev-is-bridged --physdev-in " + vif + " -j " +  vmchain)
execute("iptables -A " + vmchain + " -m physdev --physdev-is-bridged --physdev-in " + vif + " -j RETURN")

sample:

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 RETURN
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 ACCEPT
iptables -A tap115i0-in -j LOG --log-prefix "tap11i5in-dropped: " --log-level 4
iptables -A tap115i0-in -j DROP

----- Mail original ----- 

De: "Alexandre DERUMIER" <aderumier at odiso.com> 
À: "Dietmar Maurer" <dietmar at proxmox.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Mercredi 22 Janvier 2014 10:02:06 
Objet: Re: [pve-devel] RFC : iptables implementation 

>>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" <aderumier at odiso.com> 
À: "Dietmar Maurer" <dietmar at proxmox.com> 
Cc: "pve-devel" <pve-devel at 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" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Mercredi 22 Janvier 2014 08:19:02 
Objet: RE: [pve-devel] RFC : iptables implementation 

> -----Original Message----- 
> From: pve-devel-bounces at pve.proxmox.com [mailto:pve-devel- 
> bounces at 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 at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 