ppp-nat und ipfw

I

itti

Well-Known Member
hi,

ich bin nach

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/dialup-firewall/index.html

vorgegangen und habe nun ipfw im kernel aktiviert, neu kompiliert, die rc.conf angepasst und die rules nach dem example auf der seite erstellt. ich habe vorher das nat vom ppp verwendet und mache das auch jetzt noch (wie auch in dem beispiel). wie siehts aber nun mit den port forwardings aus? werden anfragen auf per ppp geforwardede ports nun geblockt oder praktischerweise gleich erlaubt? wenn sie geblockt werden, ists dann nicht besser natd zu verwenden? NOCH habe ich nicht neugestartet, also ist die config noch nicht aktiv im moment.
 
nunja ich hab sie sogar erlaubt aber irgendwie bekommen meine rechner HINTER dem gateway immer noch keine webseiten zu sehen, geschweige denn emule würde funktionieren... ich poste mal die fwrules

Code: 
# Define the firewall command (as in /etc/rc.firewall) for easy
# reference.  Helps to make it easier to read.
fwcmd="/sbin/ipfw"

# Define our outside interface.  With userland-ppp this
# defaults to tun0.
oif="tun0"

# Define our inside interface.  This is usually your network
# card.  Be sure to change this to match your own network 
# interface.
iif="rl0"

# Force a flushing of the current rules before we reload.
$fwcmd -f flush

# Check the state of all packets.
$fwcmd add check-state

# Stop spoofing on the outside interface.
$fwcmd add deny ip from any to any in via $oif not verrevpath

# Allow all connections that we initiate, and keep their state.
# but deny established connections that don't have a dynamic rule.
$fwcmd add allow ip from me to any out via $oif keep-state
$fwcmd add deny tcp from any to any established in via $oif

# Allow all connections within our network.
$fwcmd add allow ip from any to any via $iif

# Allow all local traffic.
$fwcmd add allow all from any to any via lo0
$fwcmd add deny all from any to 127.0.0.0/8
$fwcmd add deny ip from 127.0.0.0/8 to any

# Allow internet users to connect to the port 22 and 80.
# This example specifically allows connections to the sshd and a
# webserver.
$fwcmd add allow tcp from any to me dst-port 22,80,21,4662,113,6881,5190,1024,27030-27039 in via $oif setup keep-state
$fwcmd add allow udp from any to me dst-port 4672,4673,1200,27000-27015,1024 in via $oif

# Allow ICMP packets: remove type 8 if you don't want your host
# to be pingable.
$fwcmd add allow icmp from any to any via $oif icmptypes 0,3,8,11,12

# Deny and log all the rest.
$fwcmd add deny log ip from any to any

muss ich ipfw evtl. noch mitteilen dass "routing" erlaubt ist, mit ner regel für das interne interface? wirklich keinen schimmer :(
 
ich hab mir nicht die mühe gemacht die regeln nachzuvollziehen, aber mach die doch einfach mal aus und schau ob es geht. dann kannst du nach und nach regeln hinzufügen.
 
ich hab noch nie mit ipfw gearbeitet... wie mach ich das? wenn ich in der rc.conf die firewall option auf "NO" stelle dann geht schonmal gakein netztraffic mehr.

oder kann mir evtl. jemand seine rules für nen dial up-router posten, damit ich ein wenig vergleichen kann.
 
das ist normal so.
ich hab in der rc.conf
firewall_enable="YES"
firewall_script="/etc/ipfw.rules"

dann kannst du in /etc/ipfw.rules deine regeln reinschreiben, z.B. für den Anfang:
ipfw -f flush
ipfw add allow ip from any to any

und schon sollte alles erlaubt werden.
 
mir würde schon reichen wenn ich irgendwo angezeigt bekommen würde WAS aufgrund von WELCHER regel (rule number) geblockt wird. wenn ich also jetzt erstmal alle regeln mit "log" versehe, WO kann ich das dann anschauen?

das routing + nat hat vor meiner aktivierung der firewall im kernel schon zuverlässig funktioniert. ich weiß auch nicht was mich geritten hat das jetzt ausprobieren zu müssen, aber eigentlich sollte es doch garnicht so wild sein.
 
Trage
Code: 
# IPFW
!ipfw
*.*                                             /var/log/firewall.log
in Deine /etc/syslogd.conf ein. Dann werden zutreffende Regeln in die /etc/log/firewall.log geschrieben.

Ansonsten gebe auch mal
Code: 
ipfw show
ein. Da lässt sich auch erkennen welche Regel zugeschlagen hat.
 
Noch mal so für mich und das Verständnis....
Wenn ich dem PPPD sage, er möge die Ports xy auf die IP z, Port xy umleiten, dann muss ich doch auch in meinem Ruleset die Ports xy freigeben, oder? Umgekehrt:
Ich brauch doch, wenn ich einen Port in meinem FWScript frei gegeben habe, diesen nicht auch noch im PPPD auf eine lokale Schnittstelle umleiten, oder?

@Maledictus:
Meinst Du jetzt den natd von ipfw(2) oder den von pppd?

Danke für die "Aufklärung",
Alex
 
natd ist komplett eigenständig.
pppd hat keinen eingebautes nat afaik.
ipfw hat auch kein nat.
ppp hat ein eigenes eingebautes nat, welches ich persönlich bevorzuge, der einfachheit wegen (manche meinen auch es sei schneller, aber das ist mir ziemlich egal).

wenn du etwas forwarden willst muss das auch erlaubt sein, recht einleutchtend :)
 
so ne kleine frage noch damit gänzlich alles verunklärt wird. was ist eigentlich mit IPDIVERT? setzt das auf bzw. unter natd? wärs nicht geschickter dann divert rules zu verwenden anstatt von nat(über ppp).
 
wenn du es genau wissen willst:
man divert

ansonsten afaik funktioniert natd und ipfw nur, wenn natd mittels divert regel die pakete "zugespielt" bekommt.
das antfällt natürlich beim ppp-nat.
 
@asg: muss ich was an meinem setup verändern um syslogd.conf überhaupt zu haben? bei mir gibts nur syslog.conf, in die hab ich ipfw eingertragen aber es wird keine firewall.log erstellt...
 
Sup,

Die firewall.log erstellst Du mit touch /var/log/firewall.log. ;)

Es ist zuerst eine leere Datei, in die dann reingeschrieben wird.
 
Hallo itti,

um jetzt noch mal zum Thema zurück zu kehren: Ich verwende auch die in PPP eingebaute NAT-Funktion. Ich habe auch etwas mit der IPFW-Forward-Regel gespielt, leider wurden die Ports nicht wie gewünscht auf einen internen Rechner weiter geleitet.
Danach bin ich wieder zur alten Methode zurück gekehrt und habe das Portforwarding in der "/etc/ppp/ppp.conf" eingetragen.
Beispiel: "nat port tcp 10.0.0.2:5900 5900"
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben