[FreeBSD] IP forward Probleem

[Verwijderd]

Hier hebben wij een FreeBSD machine staan "FreeBSD 4.5-Release"

Eerst had ik een probleem met een ISA kaart >> Zie dit topic [rml][ FreeBSD] ISA netwerkkaart[/rml]
Dat probleem is opgelost.

Deze pc bevat nog steeds 5 netwerkkaarten:

4x 3com 3c905c (PCI)
1x 3COM NIC (ISA)

Met ifconfig herkent hij deze netwerkkaarten:
xl0, xl1, xl2. xl3 en ed0

Nu hebben wij alle netwerkkaarten ingesteld op de goede ip's en broadcast. We gebruiken nu maar even twee ip's omdat we even testen of ie wilt forwarden.

xl0= inet 3.227.111.249 netmask 0xffffff00 broadcast 3.227.111.255
xl1= inet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255


Xl0 hebben we op het normale netwerk aangesloten.
xl1 hebben we op een aparte hub aangesloten en daar een test pc aangehangen die moet gaan kijken of de freebsd bak wilt gaan forwarden.
xl2, xl3 en ed0 zijn dus niet aangesloten en dus ook niet Active.

Nu heb ik het volgende al ingesteld:
in /etc/rc.conf heb ik het volgende veranderd:

code:

defaultrouter="192.168.8.1"
gateway_enable="YES"
inetd_enable="NO"

in /etc/defaults/rc.conf heb ik het volgende veranderd:

code:

firewall_enable="YES"
firewall_script="/etc/rc.firewall"
firewall_type="OPEN"
firewall_quiet="NO"

In de kernel heb ik het volgende toegevoegd:

code:

options       IPFIREWALL
options       IPDIVERT

En netstat -r geeft de volgende routes aan:

code:

Internet:
Destination         Gateway                Flags       Refs      Use    Netif     Expire
default             192.168.1.1            UGSc         1        10      ed0
3.227.111/24        link#1                 UC           2         0      xl0
3.227.111.249       0:10:22:fd:fa:97       UHLW         20       40      lo0
localhost           localhost              UH           0         0      lo0
192.168.8           link#2                 UC           1         0      xl1

//Er staat nog meer in netstat -r maar die hebben met de andere NIC's te maken.
//En srry dat de tabel onduidelijk is

We willen namelijk geen NAT gebruiken op het netwerk. Dus Natd en IP-Masqerading vallen af.
Ook routed gebruiken we niet omdat die gebruik maakt van RIP


Op de test pc staat dit ingesteld:

IP=192.168.8.239
Gateway=192.168.8.1


Als ik op de testpc een ping uitvoer 192.168.8.1 (naar de router) krijg ik reply terug
Als ik op de testpc een ping uitvoer naar 3.227.111.249 krijg ik ook een reply terug

Dus de bsd bak kan intern wel pingen naar een andere nic.

Op de freebsd pc kan ik heel simpel naar iedere pc op het netwerk pingen.

Maar als ik nou eens naar 3.227.111.157 ping. Dit is mijn Werkstation op het netwerk. Dat dus in hetzelfde subnet zit als de nic, krijg ik een timeout.

Ofwel er zit ergens een fout op de bsd pc waardoor hij niet verder kan pingen dan zijn eigen netwerkkaart. Ik heb al vele dingen geprobeerd en veel gezocht op:
www.freebsd.org
www.bsdfreaks.nl
www.google.com/bsd
Maar dit allemaal zonder enig suc6

Als er nog meer info geplaatst moet worden, zeg het maar


Alvast bedankt..

[Infern0]

Als ik het goed begrijp kun je vanaf de FreeBSD machine (met 1001 netwerk kaarten) niet je werkstation pingen. (dan klopt dit toch niet:

Op de freebsd pc kan ik heel simpel naar iedere pc op het netwerk pingen.

)

Als je alleen deze xl0= inet 3.227.111.249 aansluit kun je dan wel je werkstation pingen?
Kun je vanaf de testpc wel je werkstation pingen?

PS. Wel een rare netwerk topologie of ligt dat aan mij?

[Verwijderd]

Deze router moet namelijk de echte router 3Com SuperstackII vervangen als deze eruit knalt.
hier even wat ik kan pingen:

TestPC -->> "xl1 Router" Succes
TestPC -->> "xl0 Router" Succes
Router -->> "TestPC" Succes
Router -->> "andere pc op het netwerkl" Succes

Grafisch:

code:

      192.168.8.1         3.227.111.239
                \                      \
   Win2k         \    FreeBSD           \    Win2k
+---------+       \ +---------+          \ +---------+
|         |        \|         |           \|         |
|         |---------|Router   |------------|         |
|         |\        |         |\           |         |
+---------+ \       +---------+ \          +---------+
             \                   \
          192.168.8.239          3.227.111.249

[Verwijderd]

rlensen schreef op 18 september 2002 @ 13:55:
Als ik het goed begrijp kun je vanaf de FreeBSD machine (met 1001 netwerk kaarten) niet je werkstation pingen. (dan klopt dit toch niet:
[...]
)

Als je alleen deze xl0= inet 3.227.111.249 aansluit kun je dan wel je werkstation pingen?
Kun je vanaf de testpc wel je werkstation pingen?

PS. Wel een rare netwerk topologie of ligt dat aan mij?

De Topologie is vele malen groter dan die ik nu schets. dit is namelijk maar even een test of hij het daadwerkelijk wilt doen. Er zijn namelijk hier 5 verschillende subnetten aanwezig. Daarom ook 5 nic's.

En ik kan vanaf mijn eigen station wel de freebsd bak pingen maar niet de testpc.

En nee vanaf de testpc kan ik niet verder pingen dan de bsd bak.

Maar:

De bsd bak begrijpt wel dat ik mijn werkstation wilt pingen want hij zoekt wel een macadres bij mijn ip. maar ik krijg geen reply terug op mijn test-pc

[Verwijderd]

hmz ....

1) Doet je firewall de pakketjes niet blocken?
2) stomme vraag, maar controleer eens met sysctl of ip_forwarding aan staat.
3) post eens de tcpdump output van de verschillende pings

[Verwijderd]

Verwijderd schreef op 18 september 2002 @ 14:46:
hmz ....

1) Doet je firewall de pakketjes niet blocken?
2) stomme vraag, maar controleer eens met sysctl of ip_forwarding aan staat.
3) post eens de tcpdump output van de verschillende pings

1)
Nee, Firewall staat op "OPEN" dus hij laat alles door

2)

Yeps, net.inet.ip.forwarding staat op 1

3)

ok, dit is mijn OutPut van de tcpdump:

code:

Output van xl1 (eigen ip adres 192.168.8.1/24)
L3-router# tcpdump -i xl1 -vvv host 192.168.8.239
tcpdump: listening on xl1
15:07:11.490061 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 128, id 51257, len 60)
15:07:12.820700 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 128, id 51258, len 60)
15:07:13.822113 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 128, id 51259, len 60)
15:07:14.823566 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 128, id 51260, len 60)
4 packets received by filter
0 packets dropped by kernel

------------------------------------------

Output van xl0 (eigen ip adres 3.227.111.249/24)
L3-router# tcpdump -i xl0 -vvv host 192.168.8.239
tcpdump: listening on xl0
15:08:10.254510 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 127, id 51261, len 60, bad cksum 0!)
15:08:11.405367 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 127, id 51262, len 60, bad cksum 0!)
15:08:12.406727 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 127, id 51263, len 60, bad cksum 0!)
15:08:13.408164 192.168.8.239 > 3.227.111.33: icmp: echo request (ttl 127, id 51264, len 60, bad cksum 0!)

4 packets received by filter
0 packets dropped by kernel

Ok, ik zie dus dat de time to live van 128 naar 127 veranderd word. Volgens mij doet de kernel dat of ben ik nou

En volgens mij geeft ie daarom ook een bad checksum

[imdos]

Nee, die ttl dat klopt wel.
En je wil dus eigenlijk een bridge bouwen is het niet

[Verwijderd]

imdos schreef op 18 September 2002 @ 15:24:
Nee, die ttl dat klopt wel.
En je wil dus eigenlijk een bridge bouwen is het niet

Tja, het moet een router worden want als die eenmaal goed routeert dan proberen we hem uit met meerdere pc's allen in hun eigen subnet.

Want beneden in het serverhok staat nu een 3-COM SuperstackII 3300 Layer3 staan. Als deze eruitknalt hebben we van 3-COM in 4 uur een nieuwe.

maar in de tussentijd moet het netwerk wel blijven werken. Dus daarom deze FreeBSD bak. Deze bevat 5 NIC's (4*pci en 1*ISA) allen van 3-COM.

Maar deze bak moet dus als router functineren. Wij hebben dus 5 verschillende subnetten en dat moet deze BSD bak voor elkaar boxen

[hbokh]

N.a.v. je eerste post:
Je moet NIET /etc/defaults/rc.conf aanpassen, maar ALLES in /etc/rc.conf
Voor zover ik weet is /etc/default/* meer een basis / voorbeeld

[Verwijderd]

met die tcpdump bedoelde ik meer dat je op _alle_ hosts tcpdump draait (eg, iedere involved nic en _zonder_ filters) en vervolgens een ping start.

Heb je nog andere network related sysctl's geset?

[Verwijderd]

hbokh schreef op 18 september 2002 @ 15:48:
N.a.v. je eerste post:
Je moet NIET /etc/defaults/rc.conf aanpassen, maar ALLES in /etc/rc.conf
Voor zover ik weet is /etc/default/* meer een basis / voorbeeld

Nee, dit is niet juist volgens mij,


Hij leest namelijk eerst /etc/defaults/rc.conf in. Dan pakt hij deze instellingen. En wat je du sin /etc/rc.conf zet dan overschrijft ie dus de instellingen die je in /etc/defaults/rc.conf hebt gezet.

Voorbeeld:
in /etc/defaults/rc.conf staat het volgende:
Gateway_enable="NO"
En in /etc/rc.conf staat deze regel:
Gateway_enable="YES"

Dan neemt ie dus de Gateway_enable="YES" instelling.

[serkoon]

Je moet gewoon met je vingertjes van defaults afblijven, klaar. Je hebt wel gelijk dat eerst defaults/rc.conf gesourced wordt, maar dat wil nog niet zeggen dat je er daarom maar in moet gaan prutsen.

/etc/rc.conf is de weg.

Verder, draai zoals gezegd eens tcpdumps op beide interfaces en kijk wat er gebeurd, zowel op layer 2 als 3 (arp en icmp dus). Er zal toch ergens iets niet goed gaan, met tcpdump kun je daar iig een flinke hint door krijgen.

[Verwijderd]

Nope, dat is echt bullshit. Je zegt dat het zo goed is dan dan spreek je je weer tegen.

En die tcpdump heb ik daar net gedraaid

[Verwijderd]

dat heb je idd gedaan, maar alleen maar op de fbsd bak. Wat ik graag zou willen zien is "tcpdump" op iedere involved machine. Zonder filters, zodat we het pad van het icmp echo-request pakketje volledig kunnen volgen, en kijken waar het pcies fout gaat. Belangrijk is dat je _zonder_ filters werkt.

[miniBSD]

kun je even de output van 'ipfw list' doorgeven ? Ik vermoed dat de natd niet correct is.

[Verwijderd]

Het probleem is opgelost.


De Client PC had een andere default GateWay ingesteld. Dus als ik hem probeerde te pingen, ontving hij de pakketjes wel maar stuurde het terug via de default GateWay. Dus de normale router. Nu ik de default Gateway hetzelfde had gezet als op de andere clientpc toen ging het wel goed.

[serkoon]

Verwijderd schreef op 19 september 2002 @ 08:49:
Nope, dat is echt bullshit. Je zegt dat het zo goed is dan dan spreek je je weer tegen.

Nee, dat zeg ik niet. Ik zeg dat je gelijk hebt dat /etc/defaults/* eerst gesourced wordt en daarna pas /etc/*.conf .. dat wil niet zeggen dat je dan maar /etc/defaults/* moet aanpassen. Dat zijn de -defaults-, die hoor je dus per definitie niet aan te passen. /etc/*.conf is de weg.

Uit man rc.conf:

code:

     The /etc/rc.conf file is included from the file /etc/defaults/rc.conf,
     which specifies the default settings for all the available options.
     Options need only be specified in /etc/rc.conf when the system adminis-
     trator wishes to [b]override[/b] these defaults.  The file /etc/rc.conf.local is
     used to [b]override[/b] settings in /etc/rc.conf for historical reasons.  See
     the ``rc_conf_files'' option below.

* serkoon is weer veel te aardig