# IPTables Regeln für XEN VMs



## BirdNerder (10. Februar 2008)

Hallo zusammen,

seit Stunden versuche ich, im für mich noch relativ neuen Thema iptables, folgendes Szenario zu verwirklichen:

Debian Etch Server mit XEN 3.0.4, 4 Debian VMs und 2 Windows VMs laufen darauf. Für eine Windows VM mit XP soll es nicht möglich sein zu pingen. Später sollte dann einmal das komplette Internet verboten sein, zum testen reicht aber erstmal der Ping. 

Für eine Debian VM (Interface vif1.0) reicht folgender Befehl

```
iptables -m physdev --physdev-in vif1.0 -p icmp -A FORWARD -j DROP
```
um aus dem Alles-Erlauben folgendes zumachen und jeglichen Ping zu unterbinden:

```
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere            PHYSDEV match --physdev-in vif1.0
```

Tue ich selbiges für die Windows VM (vif6.0) pingt er munter weiter:

```
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere            PHYSDEV match --physdev-in vif1.0
DROP       icmp --  anywhere             anywhere            PHYSDEV match --physdev-in vif6.0
```

Ich habe schon viele Kombinationen ausprobiert. Sei es physdev-out, Kombination mit der xenbr0, peth0 und eth0, im INPUT sowohl als auch im OUTPUT. Ohne Erfolg. 

Die Xen-Konfiguration (Windows: vif = [ 'type=ioemu, bridge=xenbr0' ]  -- Debian vif = [ '' ]) müsste so stimmen da das Windows sonst gar keine Verbindung hat. 

ifconfig sieht so aus (lo rausgeschnitten): 

```
eth0      Protokoll:Ethernet  Hardware Adresse 00:10:5A:B1:30:7D
          inet Adresse:192.168.2.39  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6 Adresse: fe80::210:5aff:feb1:307d/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6718 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6249 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:0
          RX bytes:454667 (444.0 KiB)  TX bytes:3216949 (3.0 MiB)

peth0     Protokoll:Ethernet  Hardware Adresse FE:FF:FF:FF:FF:FF
          inet6 Adresse: fe80::fcff:ffff:feff:ffff/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:7636 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8506 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:1000
          RX bytes:877975 (857.3 KiB)  TX bytes:3423742 (3.2 MiB)
          Interrupt:21 Basisadresse:0xcc00

tap0      Protokoll:Ethernet  Hardware Adresse C2:5C:0E:BD:50:76
          inet6 Adresse: fe80::c05c:eff:febd:5076/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:386 errors:0 dropped:0 overruns:0 frame:0
          TX packets:450 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:500
          RX bytes:46475 (45.3 KiB)  TX bytes:294810 (287.9 KiB)

vif0.0    Protokoll:Ethernet  Hardware Adresse FE:FF:FF:FF:FF:FF
          inet6 Adresse: fe80::fcff:ffff:feff:ffff/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:6249 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6718 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:0
          RX bytes:3216949 (3.0 MiB)  TX bytes:454667 (444.0 KiB)

vif1.0    Protokoll:Ethernet  Hardware Adresse FE:FF:FF:FF:FF:FF
          inet6 Adresse: fe80::fcff:ffff:feff:ffff/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:210 errors:0 dropped:0 overruns:0 frame:0
          TX packets:588 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:0
          RX bytes:23778 (23.2 KiB)  TX bytes:66383 (64.8 KiB)

vif6.0    Protokoll:Ethernet  Hardware Adresse FE:FF:FF:FF:FF:FF
          UP BROADCAST NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

xenbr0    Protokoll:Ethernet  Hardware Adresse C2:5C:0E:BD:50:76
          inet6 Adresse: fe80::200:ff:fe00:0/64 GÃ¼ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:303 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:0
          RX bytes:31774 (31.0 KiB)  TX bytes:0 (0.0 b)
```

Langsam glaube ich ich stehe voll auf der Leitung. Wie kann ich für die Windows VM den Ping über IPTables unterbinden?

Ich bin euch für jede Idee dankbar!

mfg Bird


----------



## ArtusPendragon (14. April 2008)

das problem ligt daran das die Windows VM nicht auf vif?.? seinen Netzwerkport hat sondern unter tap0 in deinem fall.

Hatte das gleiche problem auch.

was leider noch bei mir dazukommt ist wenn mehrer Windows VM laufen dann kann es passieren wenn zwei oder mehr VM neustarten das diese dann ihre tab devices tauschen.

deswegen such ich noch nach einer möglichkeit genau rauszufinden weche windows VM gerade welches Tap device benutzt.

bei normalen Linux VM´s kann man das in der config festnagel mit vifname=blub


----------



## Dennis Wronka (14. April 2008)

Wo genau der Traffic langlaeuft kannst Du am besten mit einem Tool wie TCPDump oder Wireshark nachvollziehen. Anhand der gewonnenen Informationen kannst Du dann Regeln erstellen.

Was ich mich persoenlich frage ist warum Du statt

```
-m physdev --physdev-in vif1.0
```
nicht einfach

```
-i vif1.0
```
nutzt.

Ich hab mir das PhysDev-Modul bislang nicht angesehen, aber zum einen denk ich nicht dass es in diesem Fall irgendeinen Vorteil bieten sollte, und nicht eventuell gar einen Nachteil bildet da vif1.0 ja nicht wirklich ein physikalisches Device ist.

Edit: So, ich hab mal was rumgetestet.
Das PhysDev-Modul spricht wirklich nur bei physikalischen Devices an, wozu aber auch Tun-/Tap-Devices zu zaehlen scheinen.
Bei Bridges greift PhysDev nicht.
Ich weiss jetzt nicht genau ob vif1.0 eine Bridge ist, aber das kannst Du mit *brctl show* herausfinden.

Aber wie gesagt, ich seh zur Zeit keinen wirklichen Vorteil beim Einsatz von *-m physdev --physdev-in* im Vergleich zu *-i*.
Letzteres kommt mit jedem Device klar, ob nun Bridge oder nicht.


----------

