Iptables masqeruade en bridges

[Keiichi]

Ik heb een vreemd probleem ontdekt nadat ik van m'n LAN adapter een bridge gemaakt heb. Mijn opstelling is als volgt:

eth0: WAN
eth1: LAN
br1: Bridge

Aan br1 heb ik eth1 gekoppeld. In iptables heb ik de regel 'iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0 . Mijn interne hosts hebben hier gewoon toegang tot internet.

Nu heb ik een tap0 device bij de bridge gestopt en nu kunnen geen van mijn interne hosts meer richting het internet.

Ik vind het raar probleem, omdat ik eigenlijk niet meer doe dan een apparaat in mijn LAN toevoegen. (al is het niet fysiek). Ik krijg de oorzaak van het probleem niet ontdekt en om eerlijk te zijn weet ik ook niet waar ik het moet zoeken. Heeft iemand suggesties of een soortgelijk probleem meegemaakt?

[Demo]

Werkt het wel als je tap0 uit de bridge gooit? Kan je eens een dump van je iptables rules posten?

[Keiichi]

Het werkt weer als tap0 uit de bridge gaat.

De output van iptables is. In mijn vraag heb ik eth6 door eth0 vervangen en eth1 door eth5 (om het even makkelijk te maken )

code:

root@nas2:~# iptables -vnL
Chain INPUT (policy ACCEPT 40M packets, 24G bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3127 1314K ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp spt:80 
   26  1236 ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp dpt:80 
3746K  377M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
41911   14M ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp spts:67:68 dpts:67:68 
    0     0 DROP       all  --  eth6   *       10.0.0.0/8           0.0.0.0/0           
    1   123 DROP       all  --  eth6   *       192.168.0.0/16       0.0.0.0/0           
    0     0 DROP       all  --  eth6   *       172.16.0.0/12        0.0.0.0/0           
 206M  171G ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
77129 4354K ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
  926 53696 ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
2358K  196M ACCEPT     icmp --  eth6   *       0.0.0.0/0            0.0.0.0/0           
 114M  113G ACCEPT     41   --  eth6   *       0.0.0.0/0            0.0.0.0/0           
7559K  577M ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 dpts:1024:65535 
3607K  184M ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpts:1024:65535 
   25  1900 ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp dpt:123 
 443K  125M ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp spt:53 
   37  1520 ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp spt:53 
 2063  102K ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
   18   748 ACCEPT     tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
 9513 4967K LOG        all  --  eth6   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
19513 4967K DROP       all  --  eth6   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp dpt:80 
    0     0 ACCEPT     udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp spt:80 

Chain FORWARD (policy ACCEPT 5388K packets, 389M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  66M   49G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 47M packets, 73G bytes)
 pkts bytes target     prot opt in     out     source               destination         



root@nas2:~# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 2935K packets, 220M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   84  4612 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2222 to:192.168.5.157:22 
 309K   17M DNAT       tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:51413 to:192.168.5.157 
1445K  171M DNAT       udp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           udp dpt:51413 to:192.168.5.157 
   81  4860 DNAT       tcp  --  eth6   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 to:192.168.5.157:21 
  729 37920 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:49152:49200 to:192.168.5.157 
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:49152:49200 to:192.168.5.157 

Chain INPUT (policy ACCEPT 1367K packets, 91M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1415K packets, 88M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 329K packets, 22M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  11M  773M MASQUERADE  all  --  *      eth6    0.0.0.0/0            0.0.0.0/0           
  745 45585 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0

[Hero of Time]

Maar als je machine als router fungeert, waarom zou je dan je WAN en LAN samenvoegen in een bridge? Het hele idee is juist dat die twee gescheiden is, dan moet je 't niet transparant gaan maken met een bridge. Dan kan je de hele firewall omzeilen.
Ik zou dus eerder eth1 (eth5 in jouw geval) met tap0 bridgen en dat zou 't nog prima moeten doen.

[gertvdijk]

Hero of Time schreef op woensdag 05 juni 2013 @ 15:19:
Maar als je machine als router fungeert, waarom zou je dan je WAN en LAN samenvoegen in een bridge?

Dat doet hij ook niet. Lees nog een keer.

[Demo]

Als ik het goed begrijp, dan zijn eth1 en tap0 samengevoegd tot br1..
Waar komt die tap0 vandaan? Kan je ook eens de output van ifconfig posten?

[Keiichi]

Hero of Time schreef op woensdag 05 juni 2013 @ 15:19:
Maar als je machine als router fungeert, waarom zou je dan je WAN en LAN samenvoegen in een bridge? Het hele idee is juist dat die twee gescheiden is, dan moet je 't niet transparant gaan maken met een bridge. Dan kan je de hele firewall omzeilen.
Ik zou dus eerder eth1 (eth5 in jouw geval) met tap0 bridgen en dat zou 't nog prima moeten doen.

De LAN is gebridge, niet de WAN. De tap devices zijn voor virtuele machines die op de routerbak draaien.

Demoniac schreef op woensdag 05 juni 2013 @ 15:21:
Als ik het goed begrijp, dan zijn eth1 en tap0 samengevoegd tot br1..
Waar komt die tap0 vandaan? Kan je ook eens de output van ifconfig posten?

De tap interface komt van een interface voor virtuele machines vandaan. Er zijn wel andere netwerkmogelijkheden voor KVM virtuele machines, maar dat is niet aan de orde voor hier

[ Voor 28% gewijzigd door Keiichi op 05-06-2013 15:26 ]

[Hero of Time]

gertvdijk schreef op woensdag 05 juni 2013 @ 15:21:
[...]

Dat doet hij ook niet. Lees nog een keer.

Idd, nu zie ik 't niet staat. Moet het weer zijn .

Keiichi schreef op woensdag 05 juni 2013 @ 15:22:
[...]


De LAN is gebridge, niet de WAN. De tap devices zijn voor virtuele machines die op de routerbak draaien.

Check, had 't verkeerd gelezen.

Heb je ook al geprobeerd om je iptables aan te passen om ipv op eth1 (eth5) de boel te zetten alles naar br0 (of br1, net wat je gebruikt).

[Keiichi]

In de iptables wordt bij de MASQUERADE rule de interface van de WAN gebruikt als outgoing interface.

Ik heb met tcpdump wat testjes gedaan. In de normale situatie wordt van internet via de router naar het internet alles mooi genatted. Een ping van m'n LAN naar het internet levert op de WAN interface op: %wan_ip% -> %extern%. Op het moment dat de tap device in forwarding state komt gaat dat naar %lan_ip% -> %extern% op de WAN interface.

Ik heb de MASQUERADE rule ook zonder outgoing interface opgegeven, zodat alles genatted wordt wat niet een lokaal subnet is. Hierbij is het gedrag hetzelfde.

[Kees]

Voor zover mijn ervaring:

1 device in een bridge = geen bridge
2 devices in een bridge = wel een bridge

je kan een bridge wel een ip geven maar een device in een bridge niet, kan wel, maar doet niets, dus je internet is dan stuk (tenzij je dus die bridge het ip van eth1 geeft)

Ik heb hier een vm server met een redelijk complexe setup, en daar zitten alle adressen aan de bridge vast

eth0+eth1+eth2+eth3 -> bond0

vlan123@bond0 -> br0.123 (ip.in.de.123vlan)
vlan456@bond0 -> br0.456 (ip.in.de.456vlan)
bond0 -> br0 (ip.in.legacyvlan)

en aan die bridges zitten dan weer een aantal vm's, totaal:

# ifconfig |grep Ethernet|wc -l
27

[ Voor 42% gewijzigd door Kees op 05-06-2013 19:36 ]

[Keiichi]

De setup is nu ook dat de bridge device het LAN ip adres heeft. Een complexe opstelling zoals jij omschrijft heb ik zelf ook op een server draaien, maar die draait niet als router en heeft van dit NAT probleem ook geen last.

Opzich kun je wel IP adressen aan een tap device toekennen. Alleen gaat ARP dan over de zeik. BV tap1 is 192.168.5.X en zit in de br1 device. Als de linux bak een who-has arp request doet, zal br1 als eerste de is-at arp response ontvangen en op die device pinnen.

[Hero of Time]

Ik zou even snel een soortgelijke opzet kunnen maken met twee VMs en dan puur NAT routing uitvoeren. Al denk ik dat ik 't antwoord al weet: 't gaat werken. Je tap0 interface is verders niet actief in een VM ten tijde van je testen, of wel?

[Keiichi]

De tap device is in die zin actief dat deze UP is en forwarding in de bridge.

-edit-

Ik heb thuis nog genoeg apparatuur staan om een 2de setup te maken. Ik ga daar vanavond/morgenavond ook eens even mee aan de slag

[ Voor 48% gewijzigd door Keiichi op 06-06-2013 14:15 ]