gateway routet nicht

homer0815

Well-Known Member
ich habe freebsd 5.4 mit pf als firewall und transparentem squid. mein problem ist das das normale routing nicht funktioniert. ppp connectet, bind und squid funktionieren. ich kann über 8080 und 80 -> 127.0.0.1:8080 ins internet aber andere dienste wie mail kommen halt nicht durch. sysctl -> net.inet.ip.forwarding ist 1.

da die kiste früher mal fileserver war hatte ich das routing deaktiviert. nun habe ich es aktiviert aber es tut sich nix. habe ich irgendwo einen schalter vergessen?

rc.conf
PHP:
kern_securelevel_enable="YES"
kern_securelevel="1"
hostname="proxy.netz.de"
ifconfig_dc0="inet 10.0.0.1 netmask 255.255.255.0 media 100baseTX mediaopt full-
ifconfig_dc1="media 100baseTX mediaopt full-duplex"
gateway_enable="YES"
pf_enable="YES"
pf_logd="YES"
pf_rules="/etc/pf.conf"
keymap="german.iso"
update_motd="NO"

pf.conf
PHP:
intern="dc0"
extern="tun0"
broad="10.0.0.255"
lan="10.0.0.0/24"
ip="10.0.0.1"

set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 10000, frags 5000 }
set loginterface $extern
set optimization aggressive
set block-policy drop
set require-order yes
set fingerprints "/etc/pf.os"
scrub on $extern all fragment reassemble random-id
nat on $extern from $intern to any -> $extern static-port
rdr on $intern inet proto tcp from any to any port www -> 127.0.0.1 port 8080

### LOOPBACK
pass quick on lo0 keep state

### INTERN
pass quick on $intern keep state

### EXTERN
block on $extern
pass out quick on $extern keep state
pass in quick on $extern inet proto tcp from any to any port 80 synproxy state

PS: noch eine 2. frage: wenn doch pf schon nat macht wieso muss dann pppd auch nochmal natten?
 
Zuletzt bearbeitet:
Es ist nur 1x nat notwendig. Solltest du es in ppp und pf aktivieren wirst du schon schnell genug mitbekommen das da etwas nicht stimmt. Sicher das deine rc.conf richtig ist? Was du mit dc1 machst sieht nicht gut aus, zumindest nicht für ein pppoe interface. Fehlt bei dc0 ein "? Wenn du schon Configs postest, dann bitte komplett!
Wenn du keine statische IP von deinem Provider bekommst, wäre ($ext_if) für deine nat rule besser geeignet. Diese Rule sollte vielmehr wie folgt heißen...

Code:
nat on $extern from $lan to any -> ($extern)
 
Zuletzt bearbeitet:
ersteinmal thx.
das bei dc1 ist nur ein kopierfehler weil bei putty die zeile nicht lang genug war ^^
sorry

ifconfig_dc0="inet 10.0.0.1 netmask 255.255.255.0 media 100baseTX mediaopt full-duplex"
zu dc1: habe noch einen switch zwischen nic und modem da ich zu faul war mir ein crossconnect zu kaufen und ich aus gewohnheit feste werte angebe.

das mit dem nat funktioniert ja auch im moment und ist nicht wirklich das problem mir liegts eher am routing warum das nicht funktioniert?!?
 
Zuletzt bearbeitet:
@homer0815

Ich denke, das siehst Du nicht ganz richtig, denn Deine NAT-Regel
nat on $extern from $intern to any -> $extern static-port
würde doch ausschließlich Pakete, die von der IP-Adresse Deines internen Interfaces (dc0) kommen betreffen, nicht aber die aus Deinem LAN.
Ich denke, dass AceX5 da schon richtig lag mit dem Hinweis auf das NAT.
Du solltest Deine Regel wohl doch mal so anpassen
Code:
nat on $extern from $lan to any -> $extern static-port
Gruß,

Ice
 
ok hab ich - war wirklich ein dummer fehler mit dem nat, war wohl zu spät gestern nacht. jetzt weis ich auch wieder was ich mir mit meiner rule gedacht habe nämlich:
nat on $extern from $intern:network to any -> ($extern) static-port
wie es in den docs von pf aufgeführt ist.

aber routing funktioniert trotzdem nicht.
 
Zuletzt bearbeitet:
homer0815 schrieb:
aber routing funktioniert trotzdem nicht.
Ich gehe eher davon aus das deine pf-Rules hier den Traffic verbieten. Poste doch einfach mal ein
Code:
# traceroute www.google.com
von einem Client.
 
traceroute www.google.com
traceroute: Warning: www.google.com has multiple addresses; using 66.102.7.147
traceroute to www.l.google.com (66.102.7.147), 64 hops max, 40 byte packets
1 access2-dsl-f.nas.tiscali.de (62.26.136.41) 49.257 ms 78.817 ms 65.506 ms
2 * * *
3 so-0-0-0.fra10.ip.tiscali.net (213.200.64.25) 65.155 ms so-1-1-0.fra10.ip.tiscali.net (213.200.65.17) 44.314 ms so-0-0-0.fra10.ip.tiscali.net (213.200.64.25) 38.724 ms
4 so-0-0-3.fra40.ip.tiscali.net (213.200.82.13) 54.918 ms 55.256 ms so-0-0-1.fra40.ip.tiscali.net (213.200.82.185) 50.860 ms
5 So4-3-0.FFTCR1.Frankfurt.opentransit.net (213.200.65.74) 50.514 ms 66.299 ms 40.632 ms
6 so-0-0-0-0.loncr2.London.opentransit.net (193.251.154.89) 107.858 ms so-1-0-0-0.fftcr2.Frankfurt.opentransit.net (193.251.132.90) 71.270 ms 61.794 ms
7 po3-0.loncr3.London.opentransit.net (193.251.242.217) 64.338 ms so-7-0-0-0.loncr2.London.opentransit.net (193.251.242.138) 66.763 ms po3-0.loncr3.London.opentransit.net (193.251.242.217) 227.143 ms
8 po2-0.loncr3.London.opentransit.net (193.251.242.21) 71.082 ms po3-0.nykcr3.NewYork.opentransit.net (193.251.243.21) 130.826 ms po2-0.loncr3.London.opentransit.net (193.251.242.21) 58.019 ms
9 po0-0.palcr1.PaloAlto.opentransit.net (193.251.240.1) 207.998 ms 207.847 ms po3-0.nykcr3.NewYork.opentransit.net (193.251.243.21) 175.832 ms
10 po14-0.palcr2.PaloAlto.opentransit.net (193.251.240.26) 240.352 ms po0-0.palcr1.PaloAlto.opentransit.net (193.251.240.1) 221.700 ms 234.595 ms
11 google-eu-customers-6.GW.opentransit.net (193.251.249.18) 295.406 ms po14-0.palcr2.PaloAlto.opentransit.net (193.251.240.26) 206.192 ms google-eu-customers-6.GW.opentransit.net (193.251.249.18) 230.492 ms
12 66.249.94.8 (66.249.94.8) 226.014 ms google-eu-customers-6.GW.opentransit.net (193.251.249.18) 228.237 ms 66.249.94.8 (66.249.94.8) 212.970 ms
13 66.249.94.8 (66.249.94.8) 352.039 ms 66.249.94.10 (66.249.94.10) 204.813 ms 64.233.174.54 (64.233.174.54) 222.073 ms
14 216.239.47.146 (216.239.47.146) 248.879 ms 216.239.49.146 (216.239.49.146) 211.303 ms 236.497 ms
15 216.239.49.142 (216.239.49.142) 229.220 ms 66.102.7.147 (66.102.7.147) 319.363 ms 216.239.49.150 (216.239.49.150) 209.605 ms
 
hab nur win clients bei denen liefert

tracert: der zielname www.google.com konnte nicht aufgelöst werden.
pathping: der zielname www.google.com konnte nicht aufgelöst werden.

also ein dns problem?

edit: habe das problem gelöst. bind hatte nur auf 127.0.0.1 gelauscht und deshalb keine anfragen aus dem lan beantwortet. routing funktioniert nun!!!
 
Zuletzt bearbeitet:
mal nebenbei, sollte man interfaces nicht moeglichst _immer_ auf auto-negotiation lassen?
 
Ja, außer man hat Probleme mit Switch & co oder erhofft sich irgendeine Verbesserung davon.
 
Zurück
Oben