linux debian jessie kvm en pfsense 2.2

[nike]

Hoi,

Ik heb thuis een intel dq77kb bordje met 2x nic.
Hierop heb ik debian Jessie geinstalleerd met daarop KVM.
1 van de VM's is pfsense wat dus thuis het gehele internet regeld.

Dus vanuit de modem rechtstreeks in eth0 wan en vanuit eth1 naar lan.

Maar schijnbaar heb ik wat veranderd maar op de host pc heb ik dus geen internet, kan niet resolven. natuurlijk is dit op te lossen door elke keer in de file resolve.conf de naam server van mijn pfsense routertje toe te voegen, maar met een reboot is dat weg, ik krijg vanuit dhcp vanuit upc elke keer deze gegevens.

Ik heb dus vast in mijn interfaces wat verkeerd staan maar weet nog niet wat.
In pfsense krijg ik keurig een extern ip adres omdat de eth0 in bridge staat.

mijn interfaces:

root@debian:~# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/

iface lo inet loopback

# The primary network interface

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto br0
iface br0 inet static
address 192.168.0.10
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.1
bridge_ports eth0


#br1 wanpoort

auto br1
iface br1 inet dhcp
bridge_ports eth1
bridge_stp on
bridge_fd 0

op br1 zit dus mijn modem rechtstreeks in (upc modem in bridge stand)

dus als ik op mijn debian bakje zit, dus niet in een VM en ik start firefox of ik wil apt-get draaien heb ik geen internet/niet resolven. ik ga vast naar de verkeerde nic.

[Hero of Time]

Waarom doe je auto eth0 en dan ook nog eens etho iface dhcp als deze onderdeel is van een bridge en juist door je pfsense gebruikt moet worden, ipv je host? Haal die hele auto eth0 en iface dhcp weg, het is nergens voor nodig en is precies de reden dat je nu gezeik hebt.

Mare, het meest verwarrende is nog wel dat je begint met eth0 is je WAN poort en bridged naar pfsense, om vervolgens in de config te doen dat eth1 icm br1 juist je WAN is. Hoe zit het nou?

In elk geval, doe GEEN DHCP op je host. Met br1 doe je dat ook. Zie je het probleem nu?

[Demo]

Volgens mij moet de WAN interface überhaupt niet gebridged worden, want dan gaat iedere VM die in die bridge komt een extern IP aanvragen. In mijn eigen host heb ik de WAN interface als fysieke netwerkkaart doorgegeven aan de router guest, die doet de DHCP-aanvraag en routeert alles.

Vwb de config heb ik op de gebridgede en gebonde interfaces iets staan als:

code:

auto eth0
iface eth0 inet manual
  up /sbin/ifconfig eth0 mtu 9000

Ik weet niet of de eerste twee regels ook nodig zijn als je niet de MTU wil aanpassen.

[Hero of Time]

De optie 'auto eth0' is niet nodig als die interface onderdeel is van een bridge. De interface zelf benoemen middels inet manual durf ik niet te zeggen, ik zou 't iig wel doen voor de zekerheid.

Overigens bepaald de bridge wat de MTU is, niet de interface.

[nike]

Hoi,

Ik zie nu dat ik het verkeerd had doorgegeven.
Mijn eth0 dus br0 is de lan kant

Eth1 waarin het modem zit is br1

Hieronder nu mijn config:

Allow-hotplug eth0
Iface eth0 inet Manual

Auto br0
Iface br0 inet static
Adress 192.168.0.1
Netmask 255.255.255.0
Gateway 192.168.0.1
DNS-nameservers 192.168.0.1
Bridge_ports eth0


Iface eth1 inet manual
Auto br1
Iface br1 inet dhcp
Bridge_ports eth1
Bridge_stp 0
Bridge_fd 0

Met de setup heb ik op de host desktop nog geen internet

[Hero of Time]

Waarom doe je nu nog steeds "iface br1 inet dhcp", als dat je WAN is? Heb je overigens het programma resolvconf geïnstalleerd? Want zonder heeft die dns-nameservers entry geen zin in je interfaces bestand.

[d1ng]

@nike
Logisch dat je geen internet hebt.

Je config zit helemaal vol met typfouten

Loop dat eerst even na...

[nike]

sorry voor de type fouten.
Ik deed het op de ipad, en die corrigeert graag.

hieronder de nieuwe interfaces.
Ik denk dat ik er bijna ben, maar het werkt nu nog niet:

code:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface lan
auto br0
iface br0 inet static
    address 192.168.0.10
    netmask 255.255.255.0
    gateway 192.168.0.1
    nameserver 192.168.0.1
    bridge_ports eth0

#allow-hotplug eth0
#iface eth0 inet manual

#br1 eth1 wan poort

#iface eth1 inet manual

auto br1
iface br1 inet manual
    bridge_ports eth1
    up /sbin/brctl setageing br1 0
    up /sbin/brctl stp br0 off

[Hero of Time]

Ok, met wat je hierboven hebt, wat moet je nou precies doen om wel internet te krijgen op die bak? Eerder had je 't er al over dat je alleen je DNS moest aanpassen, maar dat zou niets uit moeten maken.

Dus wat heb je nu, hoe ziet je running config eruit, route tabel en resolv.conf.

En alsjeblieft, gebruik [code] en [/code] om je config neer te zetten.

[nike]

Ik heb nu resolv.conf opgeschoond, en nu werkt alles weer naar behoren.
Omdat ik natuurlijk dhcp aanhad op mijn eth1 had hij mijn resolv.conf met de gegevens van mijn isp ingevuld.

Maar omdat ik pfsense in een vm heb draaien kon hij natuurlijk niet goed resolven.
Bedankt in ieder geval.

[Hero of Time]

Ik vind 't toch vreemd dat je geen degelijk werkende DNS hebt, als de DNS servers van je provider ingesteld staan. Het zou netwerktechnisch niets uit moeten maken, het DNS verkeer zou gewoon door je VM gerouteerd moeten worden. Je zou net zo goed de DNS servers van Google of OpenDNS moeten kunnen gebruiken.

[nike]

Ik snap wat je bedoel Hero,
Netwerk technisch zou het niet uit moeten maken.
Op een gegeven Moment twijfel je aan alles en zit zit je zoveel dingen te wijzigen/proberen dat je het ook ineens niet meer weet wat je gewijzigd heb als het werkt.

[Hero of Time]

Dat is ook een van de redenen waarom ik mensen niet snel geloof als ze roepen 'ik heb geen internet meer', als ze met dit soort netwerk dingen bezig zijn. Je doet altijd eerst een paar standaard testjes, zoals nslookup voor werking DNS en ping voor werking routes. Als DNS niet het antwoord geeft wat je verwacht, maar ping wel aantoont dat je naar buiten kan, is het in 99% van de gevallen een verkeerd ingestelde DNS.

Enige wat ik kan bedenken in jouw situatie, is dat je van pfSense niet met DNS requests door de VM mag. Wel er in, het mag er zelf uit, maar meer niet, geen routering van DNS verkeer zoals je met http dat wel hebt. Heel eigenaardig iig en niet de standaard configuratie van pfSense.