[FreeBSD 10] Nat PF und Jail - Internet bricht weg nach rebuild world

lockdoc

Well-Known Member
Hi,

seitdem ich mir FreeBSD 10 neugebaut habe, scheint es wohl ein paar Probleme mit dem NAT fuer die Jails zu geben.
Das Internet darin bricht staendig weg.

Was genau passiert?
Ich bin in einer Jail und will via den Ports ein Programm installieren.
In der Jail wird dann angefangen, den noch nicht vorhandenen Port downzuloaden.
Allerdings bricht das regelmaessig ab. Nach ein paar runtergeladenen kilobyte ist dann schluss und die Installation bricht ab, weil die Datei nicht vollstaendig geladen wurde.
Das passiert immer und immer wieder.

Ein Beispiel hier (es kommt immer ein Connection reset by peer)
Code:
fetch: ftp://ftp.se.postgresql.org/pub/databases/relational/postgresql/source/v9.0.14/postgresql-9.0.14.tar.bz2: Connection reset by peer



Mache ich das selbe allerdings vom Host aus, funktioniert es wunder bar.


Darum habe ich mir gedacht, dass es da irgendwo ein paar Probleme mit meiner neuen Kernel und PF geben muss.
In der dmesg habe ich folgende Eintraege fuer PF gefunden:

Code:
root> dmesg -a|grep pf
Starting pflog.
Nov  5 02:21:34 pflogd[822]: [priv]: msg PRIV_OPEN_LOG received
Enabling pfNo ALTQ support in kernel
[zone: pf states] PF states limit reached
[zone: pf states] PF states limit reached
[zone: pf states] PF states limit reached
[zone: pf states] PF states limit reached
[zone: pf states] PF states limit reached
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled

Die Kernel und Welt habe ich aus folgendem Branch gebaut
Code:
root> svnlite info
URL: http://svn.freebsd.org/base/stable/10
...
Revision: 257632
...
Last Changed Date: 2013-11-04 14:01:29 +0100 (Mon, 04 Nov 2013)

Code:
root> uname -a
FreeBSD fileserver.domain.lan 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r257632: Tue Nov  5 00:00:18 CET 2013     root@fileserver.domain.lan:/usr/obj/usr/src/sys/FILESERVER  amd64


Die einzigen Anpassungen, die ich an der Kernel conf gemacht habe sind wie folgt:

Code:
#makeoptions    DEBUG=-g        # Build kernel with gdb(1) debug symbols
#makeoptions    WITH_CTF=1      # Run ctfconvert(1) for DTrace support

device      pf
device      pflog

nooptions   SCTP
options     VIMAGE
device      epair
device      if_bridge

options     NULLFS
...
# Allerdings wird SCTP weiter unten durch den default ueberschrieben
options     SCTP            # Stream Control Transmission Protoco


Koennte das ganze irgendwie an SCTP in Zusammenhang mit VIMAGE sein?
Bevor ich die Kernel und Welt gebaut habe, lief es alles Problemlos.

Dazu muss ich auch sagen, dass meine vorhandenen Jails aus Beta-1 oder Beta-2 gebaut worden sind, ohne custom Kernel.
 
Zuletzt bearbeitet:
Die beiden Kommandos habe ich jetzt kurz nachdem der download von virtualbox aus der jail abgebrochen ist, abgefeuert.

Code:
pfctl -si
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 0 days 22:17:43           Debug: Urgent

State Table                          Total             Rate
  current entries                       12              
  searches                          572670            7.1/s
  inserts                              920            0.0/s
  removals                             908            0.0/s
Counters
  match                             485527            6.0/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                           1281            0.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                       107            0.0/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s

Code:
pfctl -sm
No ALTQ support in kernel
ALTQ related functions disabled
states        hard limit    10000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit   200000
 
Hmm, irgendwie hatte sich das Problem geloest, nachdem ich nochmal die neuesten Sources gezogen hatte und Kernel und world neugebaut hatte.

Code:
user> cd /usr/src
user> svnlite info 
 Revision: 257743


Die neuen angepassten Kernel Settings sind wie folgt.
Code:
cpu         HAMMER
ident       FILESERVER

options     SC_KERNEL_CONS_ATTR=(FG_GREEN|BG_BLACK)
device      pf
device      pflog
device      pfsync
#options    ALTQ
#options    ALTQ_HFSC
#options    ALTQ_NOPCC

options     IPSTEALTH
nooptions   SCTP
options     VIMAGE
device      epair
device      if_bridge
options     NULLFS

makeoptions DEBUG=-g        # Build kernel with gdb(1) debug symbols
makeoptions WITH_CTF=1      # Run ctfconvert(1) for DTrace support

(...)
options     TCP_OFFLOAD     # TCP offload
#options    SCTP            # Stream Control Transmission Protocol
options     FFS         # Berkeley Fast Filesystem
(...)


Allerdings trat das Problem gerade eben wieder auf, nachdem ich Samba in der Jail neu bauen wollte.
Connection Reset by Peer


Google scheint hier auch ein paar hits zu "FreeBSD Jail Connection reset by peer" haben, allerdings auch ohne Aufschluess und Loesung.

http://forums.freebsd.org/showthread.php?t=8524
http://feedbsd.org/discussion/14145
http://www.faultserver.com/q/answer...-outbound-connections-fail-from-j-487649.html

Hat noch Jemand hier das Problem?
 
Nachtrag:

Meine dmesg ist voll mit dem Kram hier.
Das passt zeitlich allerdings nicht zum 'connection reset by peer'
Code:
(...)
Nov 17 05:01:10 ldap adjkerntz[65596]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:01:10 intranet adjkerntz[65598]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:01:12 mail adjkerntz[65600]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:01:13 nas adjkerntz[65592]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:01:14 ntp adjkerntz[65594]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:31:01 mail adjkerntz[66178]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
Nov 17 05:31:02 dns adjkerntz[66177]: sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted
(...)

Irgendwo hatte ich noch gelesen gehabt, dass eventuell die Firewall seinen 'state' terminiert da es keine Aktivitaet auf der Verbindung gibt.
Das glaube ich bei mir eher weniger, da ich ja versuche aktiv etwas runterzuladen.

Nach dem neuen Kernel/World Build hat pf auch keine Eintraege mehr in der dmesg (anders wie im ersten Post)
Code:
root> dmesg -a|grep pf
-- leer --


pf.conf was fuer das NAT der Jails sorgt sieht wie folgt aus:
Code:
if_ext="em1"
lan_int="{192.168.0.0/24}"

nat on $if_ext from $lan_int to any -> ($if_ext)
 
Hi,
die Einträge "sysctl(set: "machdep.wall_cmos_clock"): Operation not permitted" sind sicherlich aus deinen Jails. Check mal die Crontab in den Jails, da kannste den Eintrag mit adjkerntz jeweils auskommentieren.
 
Danke erstmal fuer den Tipp mit adjkerntz. Das habe ich in den Jails jetzt ausgestellt.

Auf dem FreeBSD Host
Code:
root> netstat -m
2068/2897/4965 mbufs in use (current/cache/total)
2046/1450/3496/2036944 mbuf clusters in use (current/cache/total/max)
2046/1447 mbuf+clusters out of packet secondary zone in use (current/cache)
0/9/9/1018472 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/301769 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169745 16k jumbo clusters in use (current/cache/total/max)
4609K/3660K/8269K bytes allocated to network (current/cache/total)
1342/2165/3493 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
1/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile

In der Samba Jail
Code:
root> netstat -m
2068/2897/4965 mbufs in use (current/cache/total)
2046/1450/3496/2036944 mbuf clusters in use (current/cache/total/max)
2046/1447 mbuf+clusters out of packet secondary zone in use (current/cache)
0/9/9/1018472 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/301769 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169745 16k jumbo clusters in use (current/cache/total/max)
4609K/3660K/8269K bytes allocated to network (current/cache/total)
1342/2165/3493 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
1/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile

Auf dem FreeBSD Host
Code:
root> netstat -sptcp
tcp:
    37305 packets sent
        22847 data packets (2612680 bytes)
        114 data packets (26533 bytes) retransmitted
        0 data packets unnecessarily retransmitted
        0 resends initiated by MTU discovery
        13747 ack-only packets (5333 delayed)
        0 URG only packets
        0 window probe packets
        2 window update packets
        595 control packets
    54188 packets received
        22658 acks (for 2611256 bytes)
        294 duplicate acks
        0 acks for unsent data
        23178 packets (4567806 bytes) received in-sequence
        29 completely duplicate packets (6477 bytes)
        0 old duplicate packets
        0 packets with some dup. data (0 bytes duped)
        95 out-of-order packets (102942 bytes)
        0 packets (0 bytes) of data after window
        0 window probes
        0 window update packets
        2 packets received after close
        0 discarded for bad checksums
        0 discarded for bad header offset fields
        0 discarded because packet too short
        0 discarded due to memory problems
    327 connection requests
    70 connection accepts
    0 bad connection attempts
    0 listen queue overflows
    0 ignored RSTs in the windows
    305 connections established (including accepts)
    394 connections closed (including 28 drops)
        79 connections updated cached RTT on close
        80 connections updated cached RTT variance on close
        6 connections updated cached ssthresh on close
    92 embryonic connections dropped
    22658 segments updated rtt (of 15262 attempts)
    312 retransmit timeouts
        10 connections dropped by rexmit timeout
    0 persist timeouts
        0 connections dropped by persist timeout
    0 Connections (fin_wait_2) dropped because of timeout
    0 keepalive timeouts
        0 keepalive probes sent
        0 connections dropped by keepalive
    21187 correct ACK header predictions
    22131 correct data packet header predictions
    70 syncache entries added
        0 retransmitted
        0 dupsyn
        0 dropped
        70 completed
        0 bucket overflow
        0 cache overflow
        0 reset
        0 stale
        0 aborted
        0 badack
        0 unreach
        0 zone failures
    70 cookies sent
    0 cookies received
    10 hostcache entries added
        0 bucket overflow
    2 SACK recovery episodes
    21 segment rexmits in SACK recovery episodes
    14324 byte rexmits in SACK recovery episodes
    60 SACK options (SACK blocks) received
    77 SACK options (SACK blocks) sent
    0 SACK scoreboard overflow
    0 packets with ECN CE bit set
    0 packets with ECN ECT(0) bit set
    0 packets with ECN ECT(1) bit set
    0 successful ECN handshakes
    0 times ECN reduced the congestion window

In der Samba Jail
Code:
root> netstat -sptcp
tcp:
    37266 packets sent
        22814 data packets (2608546 bytes)
        114 data packets (26533 bytes) retransmitted
        23155 packets (4566888 bytes) received in-sequence
        29 completely duplicate packets (6477 bytes)
        0 old duplicate packets
        0 packets with some dup. data (0 bytes duped)
        95 out-of-order packets (102942 bytes)
        0 packets (0 bytes) of data after window
        0 window probes
        0 window update packets
        2 packets received after close
        0 discarded for bad checksums
        0 discarded for bad header offset fields
        0 discarded because packet too short
        0 discarded due to memory problems
    327 connection requests
    70 connection accepts
    0 bad connection attempts
    0 listen queue overflows
    0 ignored RSTs in the windows
    305 connections established (including accepts)
    393 connections closed (including 28 drops)
        77 connections updated cached RTT on close
        78 connections updated cached RTT variance on close
        6 connections updated cached ssthresh on close
    92 embryonic connections dropped
    22623 segments updated rtt (of 15238 attempts)
    312 retransmit timeouts
        10 connections dropped by rexmit timeout
    0 persist timeouts
        0 connections dropped by persist timeout
    0 Connections (fin_wait_2) dropped because of timeout
    0 keepalive timeouts
        0 keepalive probes sent
        0 connections dropped by keepalive
    21156 correct ACK header predictions
    22112 correct data packet header predictions
    70 syncache entries added
        0 retransmitted
        0 dupsyn
        0 dropped
        70 completed
        0 bucket overflow
        0 cache overflow
        0 reset
        0 stale
        0 aborted
        0 badack
        0 unreach
        0 zone failures
    70 cookies sent
    0 cookies received
    10 hostcache entries added
        0 bucket overflow
    2 SACK recovery episodes
    21 segment rexmits in SACK recovery episodes
    14324 byte rexmits in SACK recovery episodes
    60 SACK options (SACK blocks) received
    77 SACK options (SACK blocks) sent
    0 SACK scoreboard overflow
    0 packets with ECN CE bit set
    0 packets with ECN ECT(0) bit set
    0 packets with ECN ECT(1) bit set
    0 successful ECN handshakes
    0 times ECN reduced the congestion window
 
Aha, schau mal in die Statistiken von netstat -m auf dem Basishost. Ich nehme erstmal an, dass die Stats der Jail eh genau die selben sind.
1342/2165/3493 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
Es kann sein, dass du zu wenig Speicher für das Netzwerk bereitstellst.
Schau dir mal die Sysctl-Variable kern.ipc.nmbclusters an und verdoppel die einfach mal.
Es kann sein, dass der Wert in die loader.conf muss und erst nach einem Reboot greift.

Rob
 
Danke fuer die Hilfe.

Ich habe jetzt folgendes gemacht:
Code:
root> sysctl -a | grep kern.ipc.nmbclusters
kern.ipc.nmbclusters: 2036944

root> sysctl kern.ipc.nmbclusters=4073888
kern.ipc.nmbclusters: 2036944 -> 4073888

Ist der folgende Eintrag so syntaktisch korrekt fuer die loader.conf?
Code:
kern.ipc.nmbclusters="4073888"

LG
 
Als kleines Update:

Anscheinend scheint das Problem nicht nur bei den Jails auf dem FreeBSD Host aufzutreten, sondern noch bei allen anderen Computern, die in dem LAN sind und durch den FreeBSD Server ihr Internet bekommen.

Beispielsweise hab ich da noch einen raspberryPI der auch DHCP und Internet bekommt und wenn dieser mittels wget Dateien >5MB runterlaedt, dann kriege ich auch relativ oft "connection reset by peer".

Das einzige was anscheinend wirklich funktioniert ist das Internet, was auf dem FreeBSD Host ist. Dort hatte ich bis jetzt noch keine dieser Fehler beim runterladen gehabt.

Also scheint hier wirklich irgendein Problem mit dem NAT zu sein
 
Also pf verwende ich. Scrubbing sagt leider mir nichts. Wo sehe ich denn, ob das eingeschaltet ist und wie stelle ich das aus?
 
Also hier nochmal der komplette output von pfctl -s all
Translations
Code:
root> pfctl -s all
[CODE]
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on em1 inet from 192.168.0.0/24 to any -> (em1) round-robin
rdr on em1 inet proto tcp from any to (em1) port = https -> 192.168.0.31 port 443
Filter
Code:
FILTER RULES:

STATES:
all udp 192.168.2.2:55808 (192.168.0.12:123) -> 176.9.7.115:123       MULTIPLE:SINGLE
all udp 192.168.2.2:61849 (192.168.0.12:123) -> 193.175.73.151:123       MULTIPLE:SINGLE
all tcp 192.168.2.2:62416 (192.168.0.208:51489) -> 46.223.86.131:8333       SYN_SENT:CLOSED
all tcp 192.168.2.2:56585 (192.168.0.208:57745) -> 25.193.126.71:8333       SYN_SENT:CLOSED
all tcp 192.168.2.2:58157 (192.168.0.208:60308) -> 188.134.122.31:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:62257 (192.168.0.208:52118) -> 176.31.159.90:443       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:51325 (192.168.0.208:35128) -> 50.178.223.203:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:52139 (192.168.0.208:33172) -> 74.72.80.176:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:57517 (192.168.0.208:37283) -> 77.37.146.211:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:63221 (192.168.0.208:36727) -> 60.177.244.156:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:61948 (192.168.0.208:56267) -> 88.13.224.226:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:58498 (192.168.0.208:34277) -> 71.234.244.127:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:54174 (192.168.0.208:36540) -> 190.205.192.134:8333       TIME_WAIT:TIME_WAIT
all tcp 192.168.2.2:63472 (192.168.0.208:47354) -> 176.9.79.196:8001       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:54692 (192.168.0.208:36197) -> 109.235.49.27:8333       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:52377 (192.168.0.208:46799) -> 50.18.159.199:443       TIME_WAIT:TIME_WAIT
all tcp 192.168.2.2:58425 (192.168.0.208:44762) -> 184.169.138.60:443       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:51083 (192.168.0.208:42087) -> 80.67.29.6:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:62868 (192.168.0.208:45602) -> 74.125.136.16:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:63110 (192.168.0.208:38190) -> 178.255.144.35:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:60253 (192.168.0.208:54468) -> 130.149.7.33:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:51854 (192.168.0.208:54480) -> 130.149.7.33:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:63110 (192.168.0.208:49409) -> 173.194.44.1:443       FIN_WAIT_2:FIN_WAIT_2
all tcp 192.168.2.2:62287 (192.168.0.208:38210) -> 178.255.144.35:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:56315 (192.168.0.208:42115) -> 80.67.29.6:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:63165 (192.168.0.208:42137) -> 80.67.29.6:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:57499 (192.168.0.208:45653) -> 74.125.136.16:993       ESTABLISHED:ESTABLISHED
all tcp 192.168.2.2:64757 (192.168.0.208:40802) -> 173.194.44.18:443       FIN_WAIT_2:FIN_WAIT_2
all tcp 192.168.2.2:51739 (192.168.0.208:52109) -> 176.31.159.90:443       ESTABLISHED:ESTABLISHED
Info
Code:
INFO:
Status: Enabled for 0 days 00:01:25           Debug: Urgent

State Table                          Total             Rate
  current entries                       29             
  searches                         1036230        12190.9/s
  inserts                            25099          295.3/s
  removals                           25118          295.5/s
Counters
  match                             676921         7963.8/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                           1832           21.6/s
  proto-cksum                            0            0.0/s
  state-mismatch                       332            3.9/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
Timeouts
Code:
TIMEOUTS:
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                  45s
tcp.closed                   90s
tcp.tsdiff                   30s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s
adaptive.start             6000 states
adaptive.end              12000 states
src.track                     0s
Limits
Code:
LIMITS:
states        hard limit    10000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit   200000

TABLES:

OS FINGERPRINTS:
710 fingerprints loaded
 
Ich hatte immer Probleme, wenn kein "scrub in all" in der pf.conf stand. Zumindest fürs NAT wirst du das IMHO auf jeden Fall brauchen damit Du ohne Paketverluste fährst.
 
Mit der "scub in all" Konfiguration ging leider ueberhaupt kein NAT und Portwarding mehr.

Ich werde mir jetzt nochmal ueber svn die allerneuesten sourcen ziehen, vimage rausschmeissen, sctp wieder einbauen und world und kernel neubauen.
 
So das ganze Problem hat sich erledigt, nachdem ich VIMAGE aus der Kernel geschmissen habe und SCTP wieder aktiviert habe

Code:
#options VIMAGE
#nooptions SCTP
...
options SCTP # Stream Control Transmission Protoco

Jetzt funktioniert das NAT wieder fuer die Jails und den Rest des Netzwerkes.
 
Ich weiss leider gar nict genau was SCTP ist, aber das ist ja immer standardmaessig aktiviert.
Zudem hatte ic SCTP ja deaktiviert, wo ich VIMAGE angeschaltet hatte.

Was ich aber an der ganzen Sache gelernt habe ist die folgende Kernel Option
Code:
options SC_KERNEL_CONS_ATTR=(FG_GREEN|BG_BLACK)

Damit werden alle Kernel Messages in gruen angezeigt und der Rest normal in weiss. Recht uebersichtlich. xD
 
SCTP ist ein Layer 4 Protokoll wie TCP und UDP. Es versucht die positiven Eigenschaften von beiden zu vereinigen. In der Praxis wird man es eher nicht finden.
 
Tja, was soll ich sagen, das Problem ist irgendwie wieder aufgetreten und ich habe keine Ahnung warum.
Ich habe jetzt erstmal pf komplett deaktiviert und habe statische Routen zum und vom Router eingerichtet, damit laeuft es erstmal stabil.

Somit kann ich jetzt Hardware Probleme komplett ausschliessen und es muss tatsaechlich am NAT von pf liegen.
 
Also ich habe auch Probleme mit pf. Wahrscheinlich ist das auf FreeBSD-10 erstmal für einige Zeit zu entwanzen.

Bei mir klappt zum Beispiel die rdr-Regel für einen transparenten Proxy nicht, also vom LAN auf Hosts *:80 Redirect auf 127.0.0.1:8118 (als Beispiel). Das zeigt schon, dass das Ding noch nicht so ganz ausgereift ist. Ich muss noch einmal morgen gegenprüfen, ob es auf FreeBSD-9.2 (auf dem gleichen Rechner) richtig funktioniert.


Vergesst was ich gesagt habe. Das, was ich will, klappt überall nicht. Der Ursprung des Problems ist, dass squid (welches solch eine Regel unterstützen kann) nicht kompilierbar (der Port findet pfvar.h nicht) ist auf FreeBSD-10 mit pf-Interception. Deswegen habe ich es mit privoxy ausprobiert, was aber Interception nicht so kann wie squid. In der Anleitung von Privoxy steht, dass man es mit pf machen kann... ich bin mir da aber jetzt nicht mehr so sicher.

Da ich den Thread nicht vom Thema abbringen will, mache ich einen anderen auf.
 
Zuletzt bearbeitet:
Zurück
Oben