Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have 64-bit ArchLinux based (3.3.8 kernel) home server. It plays mythtv backend/file/VoIP server. It is also my gw/firewall to internet (2 nic, iptables fw). fw is setup in "deny all" style (-P INPUT DROP, -P FORWARD DROP)

I also setup kvm on this machine. KVM networking is via vde with vde's tap0 bridged to eth0 (my LAN facing phy interface).

Network subnet is 192.168.1.0

kvm(.190)<-->vde(tap0)<->bridge(name=lan0; ip=.254)<->nic0(phy dev)

kvm works, I can bidirectionally communicate between kvm guest(.190) and host(.254) - but not with my LAN hosts! Issue seems to be related to -P FORWARD DROP rule in my firewall as not executing this rule allows to work all networking OK. I have problem to understand why -P FORWARD DROP causes issue. From L3 perspective, kvm network interface is behind LAN nic (it is bridged to LAN nic) so on L3 level it should work. It looks like -P FORWARD DROP is blocking traffic from other LAN hosts. Why this?

thx in advance

share|improve this question

closed as off-topic by Wesley, Ward, cole, Falcon Momot, RolandoMySQLDBA Oct 29 '13 at 18:13

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is a site dedicated to professionals; novice questions are off-topic. Please see the Help Center for more information on topicality. The best advice we can give you is to hire a professional to help you out." – Ward, cole, Falcon Momot, RolandoMySQLDBA
If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer 1

It looks like adding -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT solves problem. From iptables man page I read: "--physdev-is-bridged Matches if the packet is being bridged and therefore is not being routed. This is only useful in the FORWARD and POSTROUTING chains." I'm wonder what security implication are from enabling this. My server has:

  • nic0: hw nic for LAN segment
  • wan0: hw nic for WAN
  • lan0: bridge
  • tap0: vde interface

nic0 & tap0 are bridged via lan0 bridge. Can I assume that -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT allows L2 traversal only for eth frames from nic0 and tap0 and eth frames from wan0 intfs to other intfs are blocked (they are limited only to wan0 ip stack area)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.