FreeBSD5.1 PPP Router

Stoni

Active Member
Hallo,

dies ist meine erste Message in diesem Forum. Kann sein, daß mein Problem schon mal behandelt wurde, habe aber beim überfliegen nichts gefunden.

Ich habe folgendes Problem: Mein Router (FreeBSD5.1) hat ein Elsa Microlink ISDN-Modem welches am seriellen Port hängt. Der Router soll den Clients im Netzwerk als Internet-Zugang dienen.

Der Zustand ist nun folgender:

tun0 ist konfiguriert, natd läuft, ipfw läuft. Wenn ich mich am Router selbst Einwähle, so ist alles fein. Ping funktioniert, DNS funktioniert, eben alles was fürs Internet gebraucht wird.

Wenn ich aber von einem Client im Netzwerk versuche, ins Internet zu kommen .... nichts. Der Router wählt sich zwar sofort ein, aber kein DNS - was mich ja noch nicht wirklich verwundert hat - aber ein Ping auf eine Internet Adresse (IP)funktioniert nicht. Die einzigen IP's welche per ping erreicht werden, sind folgende:
Router: LAN Interface, Tun0 Interface

Die IP des Providers (default-Gateway) ist nicht mehr erreichbar, wohlgemerkt nur vom Client aus nicht, vom Router aus schon.

Also glaube ich, ein Routing Problem zu haben.

Meine Konfiguration sieht folgendermaßen aus:

Kernel kompiliert:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT

rc.conf:
network_interfaces="rl0 tun0 lo0"
ifconfig_tun0=
gateway_enable="YES"
firewall_enable="YES"
firewall_type="/etc/ipfw.conf"
natd_enable="YES"
natd_flags="-f /etc/natd.conf"
natd_interface="tun0"

/etc/start_if.tun0
Inhalt: ppp -auto meinprovider

/etc/ppp/ppp.conf
meinprovider:
set phone ....
set authname ...
set authkey ...

/etc/natd.conf:
unregistered_only
use_sockets
interface tun0
dynamic

zur /etc/ipfw.conf habe ich folgende Zeilen hinzugefügt:
add 50 divert natd all from any to any via tun0
add 65000 allow all from any to any


Kann mir jemand helfen, das Problem zu lösen?

Gruß, Dirk
 
zum Annähern ans Problem mal tcpdump auf die Interfaces des Routers starten dann ping vom client absenden. IPFW checken.
Ich meine, ähnliche Probleme gehabt zu haben. Nachdem ich divert disabled habe, funzte es.

cheers
 
Maledictus schrieb:
gib mir ein ipfw show und ein netstat -r vom server und vom client.

was ich noch vergessen hatte, in /etc/sysctl.conf habe ich noch folgendes gesetzt:
net.inet.ip.forwarding=1

-----

bastion# netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 212.6.112.115 UGSc 2 0 tun0
10.0.1/24 link#3 UC 1 0 rl0
10.0.1.211 00:a0:b0:00:0e:b6 UHLW 1 79 rl0 1022
localhost localhost UH 0 0 lo0
212.6.112.115 dialin-80-228-57-1 UH 3 0 tun0

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UH lo0
fe80::%lo0 fe80::1%lo0 Uc lo0
fe80::1%lo0 link#2 UHL lo0
fe80::%rl0 link#3 UC rl0
fe80::2a0:b0ff:fe0 00:a0:b0:00:1c:6d UHL lo0
ff01:: ::1 U lo0
ff02::%lo0 ::1 UC lo0
ff02::%rl0 link#3 UC rl0
ff02::%tun0 fe80::2a0:b0ff:fe0 UC tun0
bastion#


-----

bastion# ipfw show
65535 1726 135095 allow ip from any to any
bastion#
 
bsd5543 schrieb:
zum Annähern ans Problem mal tcpdump auf die Interfaces des Routers starten dann ping vom client absenden. IPFW checken.
Ich meine, ähnliche Probleme gehabt zu haben. Nachdem ich divert disabled habe, funzte es.

cheers

divert und ipfw hatte ich probehalber ganz abgeschaltet, selbes Ergebnis ...


16:01:36.687237 10.0.1.211 > www.heise.de: icmp: echo request
16:01:38.188910 10.0.1.211 > www.heise.de: icmp: echo request
16:01:44.364534 10.0.1.211.1575 > bastion.domain: 1+ A? www.heise.de. (30)
16:01:44.364611 bastion > 10.0.1.211: icmp: bastion udp port domain unreachable
16:01:44.364756 10.0.1.211.1576 > 192.168.2.1.domain: 1+ A? www.heise.de. (30)
16:01:45.364972 10.0.1.211.1575 > bastion.domain: 1+ A? www.heise.de. (30)
16:01:45.365056 bastion > 10.0.1.211: icmp: bastion udp port domain unreachable
16:01:45.365079 10.0.1.211.1576 > 192.168.2.1.domain: 1+ A? www.heise.de. (30)
16:01:45.865577 10.0.1.211.1575 > ns.informatik.uni-bremen.de.domain: 1+ A? www.heise.de. (30)
16:01:45.865656 10.0.1.211.1576 > 192.168.2.2.domain: 1+ A? www.heise.de. (30)
16:01:47.865958 10.0.1.211.1575 > bastion.domain: 1+ A? www.heise.de. (30)
16:01:47.866037 bastion > 10.0.1.211: icmp: bastion udp port domain unreachable
16:01:47.866060 10.0.1.211.1576 > 192.168.2.1.domain: 1+ A? www.heise.de. (30)
16:01:47.866110 10.0.1.211.1575 > ns.informatik.uni-bremen.de.domain: 1+ A? www.heise.de. (30)
16:01:47.866182 10.0.1.211.1576 > 192.168.2.2.domain: 1+ A? www.heise.de. (30)
16:01:51.866718 10.0.1.211.1575 > bastion.domain: 1+ A? www.heise.de. (30)
16:01:51.866800 bastion > 10.0.1.211: icmp: bastion udp port domain unreachable
16:01:51.866822 10.0.1.211.1576 > 192.168.2.1.domain: 1+ A? www.heise.de. (30)
16:01:51.866871 10.0.1.211.1575 > ns.informatik.uni-bremen.de.domain: 1+ A? www.heise.de. (30)
16:01:51.866944 10.0.1.211.1576 > 192.168.2.2.domain: 1+ A? www.heise.de. (30)
16:02:02.498515 10.0.1.211 > bastion: icmp: echo request
16:02:02.498581 bastion > 10.0.1.211: icmp: echo reply
16:02:03.509883 10.0.1.211 > bastion: icmp: echo request
16:02:03.509941 bastion > 10.0.1.211: icmp: echo reply
16:02:04.521170 10.0.1.211 > bastion: icmp: echo request
16:02:04.521236 bastion > 10.0.1.211: icmp: echo reply
16:02:05.532338 10.0.1.211 > bastion: icmp: echo request
16:02:05.532396 bastion > 10.0.1.211: icmp: echo reply
Jun 5 16:02:08 bastion kernel: rl0: promiscuous mode disabled
 
Danke für alle, die sich Gedanken gemacht haben. Ich habe das Problem mittlerweile gelöst.

Folgendes:

Das tun0 Device wurde mit dem String 'ppp -auto provider' zur automatischen Einwahl angeregt. Diese Settings erlauben allerdings nur 'localhost-nat', nicht aber 'netzwerk-nat'. Diesen kleinen Unterschied verschweigt einem leider das Deutsche FreeBSD4.x Handbuch von freeX.

Ein Blick in das Englische FreeBSD Handbook 2nd Edition gibt einen Hinweiß auf aliase. Man möge doch mal genau 'man ppp' studieren.

Und siehe da: ein String 'ppp -auto -nat provider' bewegt dann das tun0 Device dazu, auch für die Netzwerkclients NAT auszuführen. Schon klappt alles wie am Schnürchen.

Es gilt also wie so oft im Computer-Alltag: RTFM (Read The Fine Manual) ;-)

Gruß, Dirk
 
Maledictus schrieb:
Read the friendly Manual :)

hast in deiner ppp.conf kein
nat enable yes
stehen?

Nein, habe ich nicht (steht auch in keinem Handbuch).
Könnte aber die Erklärung sein. Entweder in der ppp.conf oder in der Zeile welche die ppp.conf auswertet muss -natd stehen.
 
Zurück
Oben