[pve-devel] RFC : iptables implementation

[Alexandre DERUMIER]

>>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