richtige NAT regel in 3.7 ?

Ryo Saeba

nie zufrieden ~.~
Hi Leute.. hab jetz nun seit 2 tagen erfolglos probiert.. aber ich schaffs einfach nicht. Alles mögliche probiert, entweder hab ich syntax error in der nat regel oder es geht trotzdem einfach nicht Oo
..
Situation ist diese: oBSD soll als DSL Router für einen Windowsrechner dienen.. Der Router selber is schon im Netz, kann von ihm aus Pingen usw.. Vom Client zum Router und umgekehrt funktioniert auch.. aber vom Client kann ich keinen internet ip pingen sowie 193.0.0.193 ..
Hatte einmal eine nat , bei der kam die antwort vom Router selber das die IP nich online wäre.. aber soweit komm ich nun nicht mehr .. :s nun kommt immer nur direkt : Zielhost nicht erreichbar.

Meine Frage: Welche NAT Regel würde bei mir funktionieren. (Ich weiss blöde frage Oo aber .. ich kriegs einfach nit auf die Reihe... >.<)
Wäre Super wenn ihr eine Antwort wüsstet.
thx
Ryo
 
zu 1.: Ja ist aktiviert
zu 2.: hab die einstellung so gemacht und er erkennt sie auch prima. aber trotzdem kommt kein ping vom client nach draussen durch.
mit der FAQ habe ich gestern nacht schon gearbeitet.. funzt nix :/

==
allgemeine frage:
ist es wichtig direkt die netzwerk devices in der nat anzugeben oder geht es auch über die variable (ext_if und int_if)?
und: mein router hängt an einem externen DSL Modem.. gibt es dabei vllt etwas besonderes zu beachten ? soll als ext_if die internetverbindung selber (tun0) oder die karte stehen?

Viele Grüße,
Tim
 
Zuletzt bearbeitet:
Der Rest der pf.conf wär mal nicht schlecht.

Aber an sich sollte "nat on tun0 from 192.168.0.0/24 to any -> (tun0)" funktionieren, wenn Du das Netzwerk noch anpasst.
 
pf mit pfctl -e aktiviert?

pf config mit pfctl -f /etc/pf.conf (neu-)geladen?

Welche Filter Rules verwendest Du?
Am Besten bitte mal komplette pf.conf posten.
 
Hi,

also, die beiden Nat Regeln von euch funktionierten leider auch nicht.. konnte mit beiden nich rauspingen, nichtmal von Router selber aus.
die PF is auch immer aktiviert, ..

hier mal meine /etc/pf.conf (nix drin außer nat grade... will halt erstmal das zum laufen bringen)

Code:
ext_if="dc0" # Netzwerkkarte die ans Modem angeschlossen ist
int_if="xl0"   # Netzwerkkarte die an den Client angeschlossen ist.. 192.168.6.1 Router - 192.168.6.2 Client

# Nat Regel (wieder in die standard Nat, aber mit ihr funzt es auch nit (also das Pingen vom Router nach draussen... das sie nicht das macht was sie soll ist mir bewusst ^^' )
nat on $ext_if from !($ext_if) -> ($ext_if:0)

vorher ging pingen noch.. ^^'
mit
nat on dc0 from xl0:network to any -> (dc0)
Jetz funzt pingen nichtmal vom router mehr... auch mit pfctl -d .. :|
viele grüße
Tim
 
Also meine nat und passive ftp rule sieht irgendwie so aus:

Code:
nat on $ext from $int:network to any -> ($ext)
rdr on $ext proto tcp from !$asterix to !$lan port ftp -> $localhost port $ftpproxy

Damit läuft es einwandfrei!
 
Ryo Saeba schrieb:
Code:
ext_if="dc0" # Netzwerkkarte die ans Modem angeschlossen ist
int_if="xl0"   # Netzwerkkarte die an den Client angeschlossen ist.. 192.168.6.1 Router - 192.168.6.2 Client

# Nat Regel (wieder in die standard Nat, aber mit ihr funzt es auch nit (also das Pingen vom Router nach draussen... das sie nicht das macht was sie soll ist mir bewusst ^^' )
nat on $ext_if from !($ext_if) -> ($ext_if:0)
wozu denn das from !($ext_if)?! das trifft auch auf allen traffic zu, der aus dem netz kommt. und was fuer ein "modem" ist denn das? dsl? dann musst du ganz sicher nicht dc0 sondern tun0 oder pppoe0 oder so als ext_if eintragen.

edit:
Code:
nat_int="{ (vlan1:network), (vlan253:network) }"
ext_if="pppoe0"

nat on $ext_if inet from $nat_int to any -> ($ext_if)
und das tut hier.
 
Zuletzt bearbeitet:
so :)

mit der regel von quantumleeks funzt es 1a :)
skype funktionierte sofort wie auch icq.
Surfen und andere sachen die einen caching nameserver brauchen gehen nicht. wie richte ich mir den denn ein (dnsmasq)?
dieses packet brache bei mir leider nur errors, und die neuste version konnte ich nich installieren (mangels wissen wie.. hab die datei nicht aus dem tar archiv rausbekommen..) -> http://www.fmi.uni-passau.de/~grafj/openbsd/3.5/files/dnsmasq-2.11.tgz

danke
 
Ryo Saeba schrieb:
so :)

mit der regel von quantumleeks funzt es 1a :)

Die Regel von quantumleeks ist semantisch die selbe wie die, die ich Dir als Tip gegeben habe (nur halt ohne Macros):

nat on $ext from $int:network to any -> ($ext)

nat on tl0 from dc0:network to any -> (tl0)

Vielleicht doch nochmal die pf Doku durchlesen:
http://www.openbsd.org/faq/pf/index.html

Surfen und andere sachen die einen caching nameserver brauchen gehen nicht.

Seit wann braucht man denn fürs surfen einen caching nameserver?
Und welche "andere sachen" brauchen den?
Bitte um Erklärung was Du genau machen möchtest und was nicht funktioniert.
 
naja ich brauch das packet dnsmasq.. surfen sollte ich damit können, bis jetz kann ich es nicht ..

warum es nun mit deiner regel nicht funktioniert hat ist das ich wohl statt tun0 noch dc0 verwendet hab.
 
Ryo Saeba schrieb:
naja ich brauch das packet dnsmasq.. surfen sollte ich damit können, bis jetz kann ich es nicht ..

warum es nun mit deiner regel nicht funktioniert hat ist das ich wohl statt tun0 noch dc0 verwendet hab.

Wie wäre es, wenn Du erst einmal statt dessen die Nameserver deines Providers nutzt?

"man resolv.conf" ist dein Freund.
 
habs nun geschafft, bin von userland ppp (oder wies heisst) zu etwas anderem gegangen ? XD ka wie es heisst...
hab die datei /etc/hostname.pppoe0 angelegt und damit gearbeitet, läuft perfekt :)
 
Kann ich gut nachvollziehen, bin auch weg von userland ppp und auf kernel pppoe umgestiegen (habe ich in einem anderen Thread erwähnt), läuft ohne Probleme und kommt vor allem mit dem 24 stündigen Wechsel der dynamischen IP Adresse bestens zurecht. Wieso willst du übrigens dnsmasq nehmen? BIND läuft doch schon chrooted, trage die Nameservers deines ISP in die /var/named/etc/named.conf ein sowie die IP-Adresse derjenigen Netzwerkkarte deines Routers, die nach draußen natted; der entsprechende Abschnitt sieht bei mir so aus:


Code:
.
.
.
acl clients {
        localnets;
        ::1;
};

options {
        version "";     // remove this to allow version queries

        listen-on    { 127.0.0.1; 10.255.255.166; };
        // listen-on-v6 { any; };
        forward only;
        forwarders { 194.25.2.129; 194.25.2.130; 194.25.2.131; 194.25.2.132; 194.25.2.133; 194.25.2.134; };

        allow-recursion { clients; };
};
.
.
.

Dann noch ein named_flags="" in die /etc/rc.conf, in die /etc/resolv.conf wird nameserver 127.0.0.1 eingetragen und gut ist!
 
@quantumleeks: gibst du mir mal deine ppp-configs?

hey!

gibst du mir mal deine ppp-config-sachen?
irgendwie sind howtos und tutorials fuer kernel-ppp(oe) naemlich irgendwie mangelware....zumindest fuer openbsd...

ich wollte dir eigentlich eine persoenliche nachricht schreiben, aber das board sagt mir, du willst nicht ;-)
 
echt nicht ? komisch *_*
naja, ich werds gleich posten, wollte ansich vllt eh ein how-to machen fürs aufsetzen eines openBSD Routers für 3.7 , weil das ebenfalls Mangelware ist und ich vllt so ein paar armen vögeln wie mir helfen kann :P
ich schicke dir gleich ma die sachen per pn, ich muss jetz erstmal weg (zeitungen verteilen xD poor mans work) dann such ich ma alles zusammen was das war, sollte aber nich viel sein wenn ich alles noch richtig weiss (3 std schlaf sind die hölle..)
So bis dann , und vielen Dank an alle die geholfen haben.
Gruß,
Ryo
 
dettus schrieb:
hey!

gibst du mir mal deine ppp-config-sachen?
irgendwie sind howtos und tutorials fuer kernel-ppp(oe) naemlich irgendwie mangelware....zumindest fuer openbsd...
Es gibt unter kernel pppoe keine ppp.configs. Mein Ordner /etc/ppp ist komplett gelöscht, ich brauche ihn nicht mehr, man 4 pppoe erklärt, wie die ganze Sache eingerichtet wird. Du kannst das Beispiel in der manpage im Grunde genommen 1:1 übernehmen, nur eben mit deinen gültigen Parametern. Meine alten ppp.configs habe ich in dem Thread "Kein ppp -ddial mit OpenBSD 3.7" gepostet. Unter FreeBSD 5.4 bin ich damit nämlich sehr gut gefahren, nur mit OBSD gab es Probleme, deswegen mein Umstieg auf kernel pppoe.

Sollte dein Zugang wirklich mal einfrieren (habe ich aber bis jetzt nicht erlebt, die Kiste ist zwei Wochen nonstop online), kannst du ihn ganz einfach mit folgenden Befehlen erneut starten (kannst ja die Sache mit einem Script verbinden, welches vielleicht alle 10 Minuten überpüft, ob die Verbindung noch aktiv ist):


Code:
route delete default
route delete 0.0.0.1
pfctl -F all -d
ifconfig pppoe0 down
ifconfig pppoe0 destroy
sh /etc/netstart pppoe0
pfctl -e -F all -f /etc/pf.conf

Das ist nur ein Beispiel. Du bist ja selbst firm genug, eine eigene Lösung zu backen.
 
quantumleeks schrieb:
Sollte dein Zugang wirklich mal einfrieren (habe ich aber bis jetzt nicht erlebt, die Kiste ist zwei Wochen nonstop online), kannst du ihn ganz einfach mit folgenden Befehlen erneut starten (kannst ja die Sache mit einem Script verbinden, welches vielleicht alle 10 Minuten überpüft, ob die Verbindung noch aktiv ist):


Code:
route delete default
route delete 0.0.0.1
pfctl -F all -d
ifconfig pppoe0 down
ifconfig pppoe0 destroy
sh /etc/netstart pppoe0
pfctl -e -F all -f /etc/pf.conf

Das ist nur ein Beispiel. Du bist ja selbst firm genug, eine eigene Lösung zu backen.
uhh, reicht da kein ifconfig pppoe0 down; ifconfig pppoe0 up wie unter netbsd?
 
Vielleicht funktioniert es, allerdings stehst du dann vor dem Problem, dass du deine alte route noch hast, die durch ein einfaches ifconfig down/up nicht gelöscht wird (oder funktioniert das bei NetBSD so?). Nehmen wir z. B. an, der DSL Access Multiplexer in der Vermittlungsstelle (oder an einem sonstigen zentralen Aufschaltpunkt) hängt sich auf oder bekommt gerade just ein Firmwareupgrade, wenn du online bist, du bekommst nach einer Weile eine neue IP zugewiesen, in der routing Tabelle steht aber noch deine vorher zugewiesene IP, wie willst du damit wieder online gehen können? Zudem ist die IP an das device pppoe0 gebunden, also muss es destroyt und wieder created werden. Bei OPBSD sollten die Netzwerkdevices über das Skript /etc/netstart aktiviert werden - im Falle von kernel pppoe0 ist damit garantiert, dass die hostname.pppoe0 mit den eingetragenen spppcontrol-Parametern korrekt ausgelesen wird.
 
also grob funktioniert das so: pppoe0 hat platzhalter-adressen, die bei einer richtigen session durch die zugewiesene und die peer-adresse ersetzt werden. bei ifconfig down sind wieder die platzhalter-adressen aktiv. zusaetzlich laeuft natuerlich ifwatchd, welcher bei einem up und down event scripts ausfuehrt, die dann die default route loeschen bzw. neu setzen. destroyen muss man das interface aber nie.
 
Auch bei OBSD werden dem pseudo-device pppoe0 Platzhalteradressen zugeordnet, die dann im Augenblick der Verbindung zur Gegenstelle ersetzt werden. NetBSD hat allerdings ein etwas unterschiedliches PPP Subsystem im Vergleich zu OBSD (z. B. fehlende ISDN Unterstützung bei letzterem) - ifwatchd fehlt im Basissystem, in den Ports ist es auch nicht enthalten, gleichwohl es gepatchte inoffizielle Versionen gibt, die unter CURRENT zuverlässig laufen sollen.
 
Zurück
Oben