From owner-freebsd-pf@FreeBSD.ORG Sun Jan 23 18:43:14 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1AA916A4CE for ; Sun, 23 Jan 2005 18:43:14 +0000 (GMT) Received: from brugere.aub.dk (fw.aub.dk [195.24.1.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED4043D1F for ; Sun, 23 Jan 2005 18:43:09 +0000 (GMT) (envelope-from techlists@motrix.dk) Received: by brugere.aub.dk (Postfix, from userid 1693) id D1AA2C441; Sun, 23 Jan 2005 19:43:04 +0100 (CET) Received: from [10.1.4.50] (jmp.aub.dk [10.1.4.50]) by brugere.aub.dk (Postfix) with ESMTP id BA796C2C6 for ; Sun, 23 Jan 2005 19:43:04 +0100 (CET) Message-ID: <41F3F039.1060101@motrix.dk> Date: Sun, 23 Jan 2005 19:43:05 +0100 From: "J. Martin Petersen" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with ftp/ftp-proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2005 18:43:15 -0000 Hi We're trying to get ftp-proxy to work on our FreeBSD 5.3 (RELENG_5_3 with pf from RELENG_5) firewall, but with no luck. Does anyone have a working pf.conf that they are willing to share? When I try to connect to an ftp server (ftp2.dk.freebsd.org), active FTP does not work. We're using a very basic pf.conf: --#-- mbh_if = "xl0" mci_if = "xl2" loo_if = "lo0" set loginterface $mci_if nat on $mci_if from $mbh_if:network to any -> ($mci_if) port 10000:61999 rdr on $mbh_if inet proto tcp from $mbh_if:network to any port ftp\ -> 127.0.0.1 port ftp-proxy block log all pass log quick on $loo_if all pass in on $mbh_if from $mbh_if:network to any pass out on $mbh_if from any to $mbh_if:network keep state pass out on $mci_if proto tcp from any to any modulate state flags S/SA pass out on $mci_if proto { udp, icmp } from any to any keep state pass in log-all on $mci_if inet proto tcp from any port 20 to $mci_if\ user proxy keep state pass in log-all on $mci_if inet proto tcp from any to ($mci_if) \ port 60000:61999 keep state user proxy pass out log-all on $mci_if inet proto tcp from ($mci_if) to any \ port { ftp ftp-data } keep state user proxy --#-- mbh_if is the internal interface and mci_if is the external. I've added ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -u proxy -m 60000 -M 61999 -t 300 -D 2 -n to inetd.conf and restarted it (omitting "-n" does not help). When I try to ftp from a machine on the internal network, it doesn't work. The debug info from ftp-proxy is: --#-- Jan 23 16:38:09 fw1 ftp-proxy[932]: accepted connection from 10.2.4.50:1295 to 195.215.30.75:21 Jan 23 16:38:09 fw1 ftp-proxy[932]: local socket is 195.24.1.196:61501 Jan 23 16:38:18 fw1 ftp-proxy[932]: Got a PORT command Jan 23 16:38:18 fw1 ftp-proxy[932]: client wants us to use 10.2.4.50:5002 Jan 23 16:38:18 fw1 ftp-proxy[932]: we want server to use 195.24.1.196:60430 Jan 23 16:38:18 fw1 ftp-proxy[932]: to server (modified): PORT 195,24,1,196,236,14^M Jan 23 16:38:18 fw1 ftp-proxy[932]: server listen socket ready Jan 23 16:39:33 fw1 ftp-proxy[932]: cannot connect data channel (Operation timed out) --#-- If I do a tcpdump, I can only see hits on rule 8 and 9, which are "pass" rules. If I change "log-all" to "log" in pf.conf, I get no output at all in tcpdump. What do I need to add/alter to get ftp working? As far as I can see, I've done (more than) what the pf-faq says in "Issues with ftp". The tcpdump showed this: --#-- 16:38:09.804164 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: S 1532469226:1532469226(0) win 65535 16:38:09.809715 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: S 852511467:852511467(0) ack 1532469227 win 65535 16:38:09.809775 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1 win 65535 16:38:09.821915 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1:24(23) ack 1 win 65535 16:38:09.915073 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 24 win 65535 16:38:13.944203 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: P 1:17(16) ack 24 win 65535 16:38:13.948888 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 24:82(58) ack 17 win 65535 16:38:14.045149 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 82 win 65535 16:38:15.255111 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: P 17:28(11) ack 82 win 65535 16:38:15.259782 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 82:127(45) ack 28 win 65535 16:38:15.260961 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 127:201(74) ack 28 win 65535 16:38:15.260991 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 201 win 65535 16:38:15.261007 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 201:208(7) ack 28 win 65535 16:38:15.261024 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 208:243(35) ack 28 win 65535 16:38:15.261038 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 243 win 65535 16:38:15.261050 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 243:296(53) ack 28 win 65535 16:38:15.261061 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 296:347(51) ack 28 win 65535 16:38:15.261073 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 347 win 65480 16:38:15.261084 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 347:403(56) ack 28 win 65535 16:38:15.261095 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 403:453(50) ack 28 win 65535 16:38:15.261108 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 453 win 65374 16:38:15.261121 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 453:506(53) ack 28 win 65535 16:38:15.261131 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 506:559(53) ack 28 win 65535 16:38:15.261145 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 559 win 65268 16:38:15.261157 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 559:612(53) ack 28 win 65535 16:38:15.261168 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 612:665(53) ack 28 win 65535 16:38:15.261182 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 665 win 65162 16:38:15.261192 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 665:715(50) ack 28 win 65535 16:38:15.261202 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 715:765(50) ack 28 win 65535 16:38:15.261214 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 765 win 65062 16:38:15.261225 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 765:817(52) ack 28 win 65535 16:38:15.261235 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 817:875(58) ack 28 win 65535 16:38:15.261248 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 875 win 64952 16:38:15.261259 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 875:928(53) ack 28 win 65535 16:38:15.261268 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 928:980(52) ack 28 win 65535 16:38:15.261282 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 980 win 64847 16:38:15.261292 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 980:1032(52) ack 28 win 65535 16:38:15.261301 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1032:1084(52) ack 28 win 65535 16:38:15.261313 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1084 win 64743 16:38:15.261397 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1084:1133(49) ack 28 win 65535 16:38:15.261408 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1133:1182(49) ack 28 win 65535 16:38:15.261424 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1182 win 64645 16:38:15.261435 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1182:1235(53) ack 28 win 65535 16:38:15.261445 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1235:1287(52) ack 28 win 65535 16:38:15.261462 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1287 win 64540 16:38:15.261472 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1287:1338(51) ack 28 win 65535 16:38:15.261482 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1338:1390(52) ack 28 win 65535 16:38:15.261495 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1390 win 64437 16:38:15.261505 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1390:1444(54) ack 28 win 65535 16:38:15.261514 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1444:1498(54) ack 28 win 65535 16:38:15.261527 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1498 win 64329 16:38:15.261538 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1498:1552(54) ack 28 win 65535 16:38:15.261547 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1552:1601(49) ack 28 win 65535 16:38:15.261560 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1601 win 64226 16:38:15.261570 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1601:1653(52) ack 28 win 65535 16:38:15.261580 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1653:1701(48) ack 28 win 65535 16:38:15.261592 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1701 win 64126 16:38:18.309202 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: P 28:54(26) ack 1701 win 65535 16:38:18.326871 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1701:1731(30) ack 54 win 65535 16:38:18.328641 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: P 54:60(6) ack 1731 win 65535 16:38:18.336245 rule 8/0(match): pass in on xl2: IP 195.215.30.75.20 > 195.24.1.196.60430: S 2496167856:2496167856(0) win 65535 16:38:18.336309 rule 8/0(match): pass out on xl2: IP 195.24.1.196.60430 > 195.215.30.75.20: S 4234689438:4234689438(0) ack 2496167857 win 65535 16:38:18.340280 rule 8/0(match): pass in on xl2: IP 195.215.30.75.20 > 195.24.1.196.60430: . ack 1 win 65535 16:38:18.340382 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1731:1788(57) ack 60 win 65535 16:38:18.340403 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > 195.24.1.196.61501: P 1788:1812(24) ack 60 win 65535 16:38:18.340423 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > 195.215.30.75.21: . ack 1812 win 65535 --#-- Cheers, Martin From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 09:14:34 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5732C16A4CE for ; Mon, 24 Jan 2005 09:14:34 +0000 (GMT) Received: from ctb-mesg1.saix.net (ctb-mesg1.saix.net [196.25.240.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6037643D1D for ; Mon, 24 Jan 2005 09:14:33 +0000 (GMT) (envelope-from shane@phpboy.co.za) Received: from phpboy (tbnb-165-63-229.telkomadsl.co.za [165.165.63.229]) by ctb-mesg1.saix.net (Postfix) with SMTP id B56FC64F6 for ; Mon, 24 Jan 2005 11:14:26 +0200 (SAST) Message-ID: <003801c501f4$faf3b210$310a0a0a@phpboy> From: "Shane James" To: Date: Mon, 24 Jan 2005 11:13:30 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: PF/ALTQ Issues X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 09:14:34 -0000 I'm running FreeBSD 5.3-Stable. The only change I've made in the generic = kernel is added the following options. device pf device pflog device pfsync=20 options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Drop options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Prioirity Queueing this Box is a P4-2.4ghz + 512Mb RAM Here is a drop of 'netstat -m' 270 mbufs in use 267/32768 mbuf clusters in use (current/max) 0/3/4496 sfbufs in use (current/peak/max) 601 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Just to show that I'm not maxing out on my mbuf's Please Excuse how uneat the ALTQ limits/rules are, but I've been playing = around quite a bit with this, to try and solve the issue. #tables table persist file "/etc/zaips" - All South African Routes(My = home country) table { 196.23.168,136, 196.14.164.130, 196.46.187.69 } ############################# # AltQ on Uplink Interface ############################# altq on $uplink_if hfsc bandwidth 100Mb queue { dflt_u, lan_u, local_u, = intl_u, monitor_u } queue dflt_u bandwidth 64Kb hfsc(default realtime 512Kb = upperlimit 512Kb) queue lan_u bandwidth 10Mb hfsc(realtime 10Mb upperlimit 10Mb) queue monitor_u bandwidth 64Kb hfsc(realtime 256Kb upperlimit = 256Kb) queue local_u bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_u_l, = blueworld-l_u, mail_u_l, unix_u_l } queue windows_u_l bandwidth 64Kb hfsc(realtime 192Kb upperlimit = 320Kb) queue blueworld-l_u bandwidth 64Kb hfsc(realtime 64Kb upperlimit = 192Kb) queue mail_u_l bandwidth 64Kb hfsc(realtime 256Kb upperlimit = 320Kb) queue unix_u_l bandwidth 256Kb hfsc(realtime 256Kb upperlimit = 256Kb) queue intl_u bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_u_i, = blueworld_u_i, mail_u_i, unix_u_i } queue windows_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) queue blueworld_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) queue mail_u_i bandwidth 64Kb hfsc(realtime 64Kb upperlimit = 64Kb) queue unix_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) ############################# # AltQ on Hosting Interface ############################# altq on $hosting_if hfsc bandwidth 100Mb queue { dflt_d, lan_d, local_d, = intl_d, sodium_d } queue dflt_d bandwidth 64Kb hfsc(default realtime 512Kb = upperlimit 512Kb) queue lan_d bandwidth 10Mb hfsc(realtime 10Mb upperlimit 10Mb) queue local_d bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_ld, = monitor_d, blueworld_ld, mail_d_l, unix_d_l } queue windows_ld bandwidth 64Kb hfsc(realtime 192Kb upperlimit = 256Kb) queue monitor_d bandwidth 64Kb hfsc(realtime 256Kb upperlimit = 256Kb) queue blueworld_ld bandwidth 64Kb hfsc(realtime 64Kb upperlimit = 128Kb) queue mail_d_l bandwidth 64Kb hfsc(realtime 256Kb upperlimit = 320Kb) queue unix_d_l bandwidth 256Kb hfsc(realtime 256Kb upperlimit = 256Kb) queue intl_d bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_d_i, = monitor_d_i, blueworld_d_i, mail_d_i, unix_d_i } queue windows_d_i bandwidth 64Kb hfsc(realtime 64Kb upperlimit = 64Kb) queue monitor_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) queue blueworld_d_i bandwidth 64Kb hfsc(realtime 32Kb upperlimit = 64Kb) queue mail_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) queue unix_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) Here is an example of how I'm assigning the traffic to one of the = queue's #International Queue's pass out on $uplink_if from to any keep state queue mail_u_i pass out on $hosting_if from any to keep state queue mail_d_i #Local Queue's pass out on $uplink_if from to keep state queue = mail_u_l pass out on $hosting_if from to keep state queue = mail_d_l Also, I am running Intel Pro 100 S(Intel Ethernet Express) Server Cards = on either interface. both cards have been swapped to confirm that it's = not a hardware related issue. Which it's not. 'pfctl -vsq' for these 4 queue's: queue mail_u_l bandwidth 256Kb hfsc( realtime 256Kb upperlimit 256Kb ) = [ pkts: 3592 bytes: 3624366 dropped pkts: 0 bytes: = 0 ] -- queue mail_u_i bandwidth 64Kb hfsc( realtime 64Kb upperlimit 64Kb )=20 [ pkts: 1277 bytes: 230620 dropped pkts: 0 bytes: = 0 ] -- queue mail_d_l bandwidth 256Kb hfsc( realtime 256Kb upperlimit 256Kb ) = [ pkts: 3933 bytes: 856087 dropped pkts: 0 bytes: = 0 ] -- queue mail_d_i bandwidth 64Kb hfsc( upperlimit 64Kb )=20 [ pkts: 1185 bytes: 1559939 dropped pkts: 0 bytes: = 0 ] Now, here is the issue. With All queue's that I add. Upstream($uplink_if) Bandwidth goes quite a = bit slower that it's suppose to. DownStream($hosting_if) runs at the = correct speeds and sometime even more that I've assigned to it. Another = strange thing though is that fact that I don't always think that it's = assigning all traffic to the correct queue's some times it uses more = bandwidth than I've assigned to the queue and some times it uses a lot = less. Despite the fact that it as all the bandwidth to it's disposal at = test time. the way I've been measuring the usage is through MRTG and lftp to hosts = on my peering network. Any Help Would be much apprecatied. Kind Regards, Shane James VirTek - http://www.virtek.co.za O: 0861 10 1107 M: +27 (0) 82 786 3878 F: +27 (0) 11 388 5626 From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 14:25:28 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22BA716A4CE for ; Mon, 24 Jan 2005 14:25:28 +0000 (GMT) Received: from mail.3gne.com (ded191-fbsd-174-39.netsonic.net [66.180.174.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E1C43D4C for ; Mon, 24 Jan 2005 14:25:26 +0000 (GMT) (envelope-from nick@buraglio.com) Received: from localhost (localhost.3gne.com [127.0.0.1]) by mail.3gne.com (Postfix) with ESMTP id 17A13D5657; Mon, 24 Jan 2005 08:31:26 -0600 (CST) Received: from [192.168.100.250] (12-221-108-48.client.insightBB.com [12.221.108.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.3gne.com (Postfix) with ESMTP id 406DDD46C1; Mon, 24 Jan 2005 08:31:23 -0600 (CST) In-Reply-To: <41F3F039.1060101@motrix.dk> References: <41F3F039.1060101@motrix.dk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Nick Buraglio Date: Mon, 24 Jan 2005 08:25:18 -0600 To: "J. Martin Petersen" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at 3gne.com cc: freebsd-pf@freebsd.org Subject: Re: Problems with ftp/ftp-proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 14:25:28 -0000 I have never used the ftp-proxy with the "user proxy" additions, but I've been using it successfully (under openbsd) in many locations with this setup (straight from the man page): /etc/inetd.conf : ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy /etc/pf.conf : -- snip -- # NAT Rules nat on $ext_if from $internal_net to any -> ($ext_if) # Redirect Rules rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 -- snip-- Granted my setups are probably much more simple, there is a default pass all, aside from the captive portal tables and altq stuff (these are not really firewalls as much as traffic cop boxes at apartment campuses and hotspots). I'm actually putting my first freebsd box in with the same setup this week, but so far testing using ftp-proxy, altq, pf and freebsd 5.3 has been good. nb On Jan 23, 2005, at 12:43 PM, J. Martin Petersen wrote: > Hi > > We're trying to get ftp-proxy to work on our FreeBSD 5.3 (RELENG_5_3 > with pf from RELENG_5) firewall, but with no luck. Does anyone have a > working pf.conf that they are willing to share? > > When I try to connect to an ftp server (ftp2.dk.freebsd.org), active > FTP > does not work. We're using a very basic pf.conf: > --#-- > mbh_if = "xl0" > mci_if = "xl2" > loo_if = "lo0" > > set loginterface $mci_if > > nat on $mci_if from $mbh_if:network to any -> ($mci_if) port > 10000:61999 > rdr on $mbh_if inet proto tcp from $mbh_if:network to any port ftp\ > -> 127.0.0.1 port ftp-proxy > > block log all > > pass log quick on $loo_if all > pass in on $mbh_if from $mbh_if:network to any > pass out on $mbh_if from any to $mbh_if:network keep state > pass out on $mci_if proto tcp from any to any modulate state flags S/SA > pass out on $mci_if proto { udp, icmp } from any to any keep state > > pass in log-all on $mci_if inet proto tcp from any port 20 to $mci_if\ > user proxy keep state > pass in log-all on $mci_if inet proto tcp from any to ($mci_if) \ > port 60000:61999 keep state user proxy > pass out log-all on $mci_if inet proto tcp from ($mci_if) to any \ > port { ftp ftp-data } keep state user proxy > --#-- > > mbh_if is the internal interface and mci_if is the external. I've added > ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -u > proxy -m 60000 -M 61999 -t 300 -D 2 -n > to inetd.conf and restarted it (omitting "-n" does not help). > > When I try to ftp from a machine on the internal network, it doesn't > work. The debug info from ftp-proxy is: > --#-- > Jan 23 16:38:09 fw1 ftp-proxy[932]: accepted connection from > 10.2.4.50:1295 to 195.215.30.75:21 > Jan 23 16:38:09 fw1 ftp-proxy[932]: local socket is 195.24.1.196:61501 > Jan 23 16:38:18 fw1 ftp-proxy[932]: Got a PORT command > Jan 23 16:38:18 fw1 ftp-proxy[932]: client wants us to use > 10.2.4.50:5002 > Jan 23 16:38:18 fw1 ftp-proxy[932]: we want server to use > 195.24.1.196:60430 > Jan 23 16:38:18 fw1 ftp-proxy[932]: to server (modified): PORT > 195,24,1,196,236,14^M > Jan 23 16:38:18 fw1 ftp-proxy[932]: server listen socket ready > Jan 23 16:39:33 fw1 ftp-proxy[932]: cannot connect data channel > (Operation timed out) > --#-- > > If I do a tcpdump, I can only see hits on rule 8 and 9, which are > "pass" > rules. If I change "log-all" to "log" in pf.conf, I get no output at > all > in tcpdump. > > What do I need to add/alter to get ftp working? As far as I can see, > I've done (more than) what the pf-faq says in "Issues with ftp". > > The tcpdump showed this: > --#-- > 16:38:09.804164 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: S 1532469226:1532469226(0) win 65535 1460,nop,nop,sackOK,[|tcp]> > 16:38:09.809715 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: S 852511467:852511467(0) ack 1532469227 win 65535 > > 16:38:09.809775 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1 win 65535 > 16:38:09.821915 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1:24(23) ack 1 win 65535 > 16:38:09.915073 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 24 win 65535 > 16:38:13.944203 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: P 1:17(16) ack 24 win 65535 > 16:38:13.948888 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 24:82(58) ack 17 win 65535 > 16:38:14.045149 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 82 win 65535 > 16:38:15.255111 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: P 17:28(11) ack 82 win 65535 > 16:38:15.259782 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 82:127(45) ack 28 win 65535 > 16:38:15.260961 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 127:201(74) ack 28 win 65535 > 16:38:15.260991 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 201 win 65535 > 16:38:15.261007 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 201:208(7) ack 28 win 65535 > 16:38:15.261024 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 208:243(35) ack 28 win 65535 > 16:38:15.261038 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 243 win 65535 > 16:38:15.261050 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 243:296(53) ack 28 win 65535 > 16:38:15.261061 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 296:347(51) ack 28 win 65535 > 16:38:15.261073 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 347 win 65480 > 16:38:15.261084 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 347:403(56) ack 28 win 65535 > 16:38:15.261095 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 403:453(50) ack 28 win 65535 > 16:38:15.261108 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 453 win 65374 > 16:38:15.261121 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 453:506(53) ack 28 win 65535 > 16:38:15.261131 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 506:559(53) ack 28 win 65535 > 16:38:15.261145 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 559 win 65268 > 16:38:15.261157 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 559:612(53) ack 28 win 65535 > 16:38:15.261168 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 612:665(53) ack 28 win 65535 > 16:38:15.261182 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 665 win 65162 > 16:38:15.261192 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 665:715(50) ack 28 win 65535 > 16:38:15.261202 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 715:765(50) ack 28 win 65535 > 16:38:15.261214 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 765 win 65062 > 16:38:15.261225 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 765:817(52) ack 28 win 65535 > 16:38:15.261235 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 817:875(58) ack 28 win 65535 > 16:38:15.261248 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 875 win 64952 > 16:38:15.261259 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 875:928(53) ack 28 win 65535 > 16:38:15.261268 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 928:980(52) ack 28 win 65535 > 16:38:15.261282 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 980 win 64847 > 16:38:15.261292 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 980:1032(52) ack 28 win 65535 > 16:38:15.261301 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1032:1084(52) ack 28 win 65535 > 16:38:15.261313 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1084 win 64743 > 16:38:15.261397 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1084:1133(49) ack 28 win 65535 > 16:38:15.261408 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1133:1182(49) ack 28 win 65535 > 16:38:15.261424 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1182 win 64645 > 16:38:15.261435 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1182:1235(53) ack 28 win 65535 > 16:38:15.261445 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1235:1287(52) ack 28 win 65535 > 16:38:15.261462 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1287 win 64540 > 16:38:15.261472 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1287:1338(51) ack 28 win 65535 > 16:38:15.261482 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1338:1390(52) ack 28 win 65535 > 16:38:15.261495 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1390 win 64437 > 16:38:15.261505 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1390:1444(54) ack 28 win 65535 > 16:38:15.261514 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1444:1498(54) ack 28 win 65535 > 16:38:15.261527 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1498 win 64329 > 16:38:15.261538 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1498:1552(54) ack 28 win 65535 > 16:38:15.261547 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1552:1601(49) ack 28 win 65535 > 16:38:15.261560 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1601 win 64226 > 16:38:15.261570 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1601:1653(52) ack 28 win 65535 > 16:38:15.261580 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1653:1701(48) ack 28 win 65535 > 16:38:15.261592 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1701 win 64126 > 16:38:18.309202 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: P 28:54(26) ack 1701 win 65535 > 16:38:18.326871 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1701:1731(30) ack 54 win 65535 > 16:38:18.328641 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: P 54:60(6) ack 1731 win 65535 > 16:38:18.336245 rule 8/0(match): pass in on xl2: IP 195.215.30.75.20 > > 195.24.1.196.60430: S 2496167856:2496167856(0) win 65535 1460,nop,nop,sackOK> > 16:38:18.336309 rule 8/0(match): pass out on xl2: IP 195.24.1.196.60430 > > 195.215.30.75.20: S 4234689438:4234689438(0) ack 2496167857 win > 65535 > > 16:38:18.340280 rule 8/0(match): pass in on xl2: IP 195.215.30.75.20 > > 195.24.1.196.60430: . ack 1 win 65535 > 16:38:18.340382 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1731:1788(57) ack 60 win 65535 > 16:38:18.340403 rule 9/0(match): pass in on xl2: IP 195.215.30.75.21 > > 195.24.1.196.61501: P 1788:1812(24) ack 60 win 65535 > 16:38:18.340423 rule 9/0(match): pass out on xl2: IP 195.24.1.196.61501 > > 195.215.30.75.21: . ack 1812 win 65535 > --#-- > > Cheers, Martin > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 14:55:49 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C660B16A4CF for ; Mon, 24 Jan 2005 14:55:49 +0000 (GMT) Received: from mail.3gne.com (ded191-fbsd-174-39.netsonic.net [66.180.174.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4606443D5D for ; Mon, 24 Jan 2005 14:55:49 +0000 (GMT) (envelope-from nick@buraglio.com) Received: from localhost (localhost.3gne.com [127.0.0.1]) by mail.3gne.com (Postfix) with ESMTP id 40C86D5620; Mon, 24 Jan 2005 09:01:49 -0600 (CST) Received: from [192.168.100.250] (12-221-108-48.client.insightBB.com [12.221.108.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.3gne.com (Postfix) with ESMTP id E2151D4215; Mon, 24 Jan 2005 09:01:45 -0600 (CST) In-Reply-To: <003801c501f4$faf3b210$310a0a0a@phpboy> References: <003801c501f4$faf3b210$310a0a0a@phpboy> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03DF541E-6E18-11D9-AF54-000D93B6DEE8@buraglio.com> Content-Transfer-Encoding: 7bit From: Nick Buraglio Date: Mon, 24 Jan 2005 08:55:40 -0600 To: "Shane James" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at 3gne.com cc: freebsd-pf@freebsd.org Subject: Re: PF/ALTQ Issues X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 14:55:50 -0000 I've found that there is a severe lack of documentation for hfsc. Anyway, when testing my QoS rules the only reliable method that I've found is iperf. It'll give you a realtime report on what you're actually trying to do, measure traffic and it supports multiple streams, multicast, etc. MRTG is recording an average if I'm not mistaken, which can sometimes be deceiving. I'm not questioning what there may be some strangeness in the hfsc queuing discipline code (I've been meaning to start using it since it seems very powerful and does exactly what I need) but in my humble opinion there isn't a much better way to measure true throughput. iperf is available in the ports collection. I know that really doesn't answer your question, but maybe it'll help get some better troubleshooting data. nb On Jan 24, 2005, at 3:13 AM, Shane James wrote: > I'm running FreeBSD 5.3-Stable. The only change I've made in the > generic kernel is added the following options. > > device pf > device pflog > device pfsync > > options ALTQ > options ALTQ_CBQ # Class Bases Queueing > options ALTQ_RED # Random Early Drop > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler > options ALTQ_CDNR # Traffic conditioner > options ALTQ_PRIQ # Prioirity Queueing > > this Box is a P4-2.4ghz + 512Mb RAM > > Here is a drop of 'netstat -m' > 270 mbufs in use > 267/32768 mbuf clusters in use (current/max) > 0/3/4496 sfbufs in use (current/peak/max) > 601 KBytes allocated to network > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Just to show that I'm not maxing out on my mbuf's > > Please Excuse how uneat the ALTQ limits/rules are, but I've been > playing around quite a bit with this, to try and solve the issue. > > #tables > table persist file "/etc/zaips" - All South African Routes(My > home country) > table { 196.23.168,136, 196.14.164.130, 196.46.187.69 } > > ############################# > # AltQ on Uplink Interface > ############################# > altq on $uplink_if hfsc bandwidth 100Mb queue { dflt_u, lan_u, > local_u, intl_u, monitor_u } > queue dflt_u bandwidth 64Kb hfsc(default realtime 512Kb > upperlimit 512Kb) > queue lan_u bandwidth 10Mb hfsc(realtime 10Mb upperlimit 10Mb) > queue monitor_u bandwidth 64Kb hfsc(realtime 256Kb upperlimit > 256Kb) > > queue local_u bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_u_l, > blueworld-l_u, mail_u_l, unix_u_l } > queue windows_u_l bandwidth 64Kb hfsc(realtime 192Kb > upperlimit 320Kb) > queue blueworld-l_u bandwidth 64Kb hfsc(realtime 64Kb > upperlimit 192Kb) > queue mail_u_l bandwidth 64Kb hfsc(realtime 256Kb upperlimit > 320Kb) > queue unix_u_l bandwidth 256Kb hfsc(realtime 256Kb upperlimit > 256Kb) > > queue intl_u bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_u_i, > blueworld_u_i, mail_u_i, unix_u_i } > queue windows_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) > queue blueworld_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) > queue mail_u_i bandwidth 64Kb hfsc(realtime 64Kb upperlimit > 64Kb) > queue unix_u_i bandwidth 64Kb hfsc(upperlimit 64Kb) > > ############################# > # AltQ on Hosting Interface > ############################# > altq on $hosting_if hfsc bandwidth 100Mb queue { dflt_d, lan_d, > local_d, intl_d, sodium_d } > queue dflt_d bandwidth 64Kb hfsc(default realtime 512Kb > upperlimit 512Kb) > queue lan_d bandwidth 10Mb hfsc(realtime 10Mb upperlimit 10Mb) > > queue local_d bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_ld, > monitor_d, blueworld_ld, mail_d_l, unix_d_l } > queue windows_ld bandwidth 64Kb hfsc(realtime 192Kb upperlimit > 256Kb) > queue monitor_d bandwidth 64Kb hfsc(realtime 256Kb upperlimit > 256Kb) > queue blueworld_ld bandwidth 64Kb hfsc(realtime 64Kb > upperlimit 128Kb) > queue mail_d_l bandwidth 64Kb hfsc(realtime 256Kb upperlimit > 320Kb) > queue unix_d_l bandwidth 256Kb hfsc(realtime 256Kb upperlimit > 256Kb) > > queue intl_d bandwidth 10Mb hfsc(upperlimit 10Mb) { windows_d_i, > monitor_d_i, blueworld_d_i, mail_d_i, unix_d_i } > queue windows_d_i bandwidth 64Kb hfsc(realtime 64Kb upperlimit > 64Kb) > queue monitor_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) > queue blueworld_d_i bandwidth 64Kb hfsc(realtime 32Kb > upperlimit 64Kb) > queue mail_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) > queue unix_d_i bandwidth 64Kb hfsc(upperlimit 64Kb) > > > Here is an example of how I'm assigning the traffic to one of the > queue's > > #International Queue's > pass out on $uplink_if from to any keep state queue mail_u_i > pass out on $hosting_if from any to keep state queue mail_d_i > > #Local Queue's > pass out on $uplink_if from to keep state queue > mail_u_l > pass out on $hosting_if from to keep state queue > mail_d_l > > Also, I am running Intel Pro 100 S(Intel Ethernet Express) Server > Cards on either interface. both cards have been swapped to confirm > that it's not a hardware related issue. Which it's not. > > 'pfctl -vsq' for these 4 queue's: > > > queue mail_u_l bandwidth 256Kb hfsc( realtime 256Kb upperlimit 256Kb > ) > [ pkts: 3592 bytes: 3624366 dropped pkts: 0 bytes: > 0 ] > -- > > queue mail_u_i bandwidth 64Kb hfsc( realtime 64Kb upperlimit 64Kb ) > [ pkts: 1277 bytes: 230620 dropped pkts: 0 bytes: > 0 ] > -- > > queue mail_d_l bandwidth 256Kb hfsc( realtime 256Kb upperlimit 256Kb > ) > [ pkts: 3933 bytes: 856087 dropped pkts: 0 bytes: > 0 ] > -- > queue mail_d_i bandwidth 64Kb hfsc( upperlimit 64Kb ) > [ pkts: 1185 bytes: 1559939 dropped pkts: 0 bytes: > 0 ] > > > Now, here is the issue. > With All queue's that I add. Upstream($uplink_if) Bandwidth goes quite > a bit slower that it's suppose to. DownStream($hosting_if) runs at the > correct speeds and sometime even more that I've assigned to it. > Another strange thing though is that fact that I don't always think > that it's assigning all traffic to the correct queue's some times it > uses more bandwidth than I've assigned to the queue and some times it > uses a lot less. Despite the fact that it as all the bandwidth to it's > disposal at test time. > > the way I've been measuring the usage is through MRTG and lftp to > hosts on my peering network. > > Any Help Would be much apprecatied. > > Kind Regards, > Shane James > VirTek - http://www.virtek.co.za > O: 0861 10 1107 > M: +27 (0) 82 786 3878 > F: +27 (0) 11 388 5626 > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 20:41:44 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 598E716A4CE for ; Mon, 24 Jan 2005 20:41:44 +0000 (GMT) Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D587943D1D for ; Mon, 24 Jan 2005 20:41:43 +0000 (GMT) (envelope-from pathiaki@pathiaki.com) Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150])j0OKfgWn032438 for ; Mon, 24 Jan 2005 15:41:42 -0500 Received: from cpe-66-189-12-20.ma.charter.com (HELO pc4.atlantisservices.com) (66.189.12.20) by mxip20.cluster1.charter.net with ESMTP; 24 Jan 2005 15:41:43 -0500 X-Ironport-AV: i="3.88,148,1102309200"; d="scan'208"; a="656282106:sNHT47114444" From: "Paul J. Pathiakis" To: freebsd-pf@freebsd.org Date: Mon, 24 Jan 2005 15:41:41 -0500 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501241541.41601.pathiaki@pathiaki.com> Subject: Dynamic Addresses and PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 20:41:44 -0000 Hi, if I'm using a DSL dynamic address, on an external i/f, should I be using the parentheses everywhere? ext_if2 = "tun0" ext_gw2 = "70.1.2.3" That is, on a NAT rule such as: nat on $ext_if2 from $lan_net2 to any -> ($ext_if2) should I write it as: nat on ($ext_if2) from $lan_net2 to any -> ($ext_if2) ? Also, since ext_if2 is declared as "tun0" for a DSLconnection, is there a way to replace ext_gw2 in all my rules be something like ($ext_if2)? That is, could I do this: ext_gw2 = ($ext_if2) at the beginning of declarations to allow the ext_gw2 variable to be set to the dynamic IP address of the ext_if2? Is this possible? Thanks! Paul Pathiakis From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 21:03:24 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D319A16A4CE for ; Mon, 24 Jan 2005 21:03:24 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8098543D53 for ; Mon, 24 Jan 2005 21:03:23 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CtBMo-0001zw-00; Mon, 24 Jan 2005 22:03:22 +0100 Received: from [217.227.156.99] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CtBMn-0004jZ-00; Mon, 24 Jan 2005 22:03:22 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Mon, 24 Jan 2005 22:03:01 +0100 User-Agent: KMail/1.7.2 References: <200501241541.41601.pathiaki@pathiaki.com> In-Reply-To: <200501241541.41601.pathiaki@pathiaki.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2435893.npx8UV9vAx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501242203.10228.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: Dynamic Addresses and PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 21:03:25 -0000 --nextPart2435893.npx8UV9vAx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 24 January 2005 21:41, Paul J. Pathiakis wrote: > Hi, > > if I'm using a DSL dynamic address, on an external i/f, should I be using > the parentheses everywhere? > > ext_if2 =3D "tun0" > ext_gw2 =3D "70.1.2.3" > > That is, on a NAT rule such as: > > nat on $ext_if2 from $lan_net2 to any -> ($ext_if2) > > should I write it as: > > nat on ($ext_if2) from $lan_net2 to any -> ($ext_if2) > > ? No. The dynamic address modifier does not apply to the "on ifspec" part. = The=20 first rule is correct, the second one won't parse. > Also, since ext_if2 is declared as "tun0" for a DSLconnection, is there a > way to replace ext_gw2 in all my rules be something like ($ext_if2)? > > That is, could I do this: > > ext_gw2 =3D ($ext_if2) > > at the beginning of declarations to allow the ext_gw2 variable to be set = to > the dynamic IP address of the ext_if2? > > Is this possible? Yes it is. You'd do: ext_if=3Dtun0 ext_gw=3D"(" $ext_if ")" be careful with the whitespaces on that. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2435893.npx8UV9vAx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB9WKOXyyEoT62BG0RArFeAJ9P3Xi83UYjjyQlIyZwP9JXDgtbKwCfTL15 7kA8ky8mRKz12/s1Nezq+NM= =2avo -----END PGP SIGNATURE----- --nextPart2435893.npx8UV9vAx-- From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 22:26:33 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE0A816A4CE for ; Mon, 24 Jan 2005 22:26:33 +0000 (GMT) Received: from hotmail.com (bay24-f23.bay24.hotmail.com [64.4.18.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF03543D3F for ; Mon, 24 Jan 2005 22:26:33 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Jan 2005 14:25:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Mon, 24 Jan 2005 22:24:13 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: freebsd-pf@freebsd.org Date: Mon, 24 Jan 2005 15:24:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Jan 2005 22:25:02.0047 (UTC) FILETIME=[8BCDDEF0:01C50263] Subject: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 22:26:34 -0000 I have a freebsd box with 2 wan interfaces, 1 lan interface and 1 tun interface. I have pf setup so that 10.1.0.64/26 and 10.1.0.128/25 go out our second wan interface like this: nat on $ext_if1 from $internal_net to any -> ($ext_if1) nat on $ext_if2 from $internal_net to any -> ($ext_if2) pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , 10.1.0.128/25 } to any pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any However, any traffic destined to 10.0.0.0/26 accessible via the tun0 interface doesn't get routed as I'm guessing it goes out to the 2nd wan interface ( $ext_if2 ). I've tried modifying the pass in line like this: pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , 10.1.0.128/25 } to { 0.0.0.0/0, !10.0.0.0/26 } However it did not work. Any suggestions on this? thanks, stephane. _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 22:34:43 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1805816A4CE for ; Mon, 24 Jan 2005 22:34:43 +0000 (GMT) Received: from brugere.aub.dk (fw.aub.dk [195.24.1.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B2B543D4C for ; Mon, 24 Jan 2005 22:34:38 +0000 (GMT) (envelope-from techlists@motrix.dk) Received: by brugere.aub.dk (Postfix, from userid 1693) id 1B3E7C498; Mon, 24 Jan 2005 23:34:35 +0100 (CET) Received: from [10.1.4.50] (jmp.aub.dk [10.1.4.50]) by brugere.aub.dk (Postfix) with ESMTP id 05D20C488; Mon, 24 Jan 2005 23:34:35 +0100 (CET) Message-ID: <41F577FA.7090300@motrix.dk> Date: Mon, 24 Jan 2005 23:34:34 +0100 From: "J. Martin Petersen" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Buraglio , freebsd-pf@freebsd.org References: <41F3F039.1060101@motrix.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems with ftp/ftp-proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 22:34:43 -0000 Nick Buraglio wrote: > I have never used the ftp-proxy with the "user proxy" additions, but > I've been using it successfully (under openbsd) in many locations with > this setup (straight from the man page): Ah, thanks for the tip. When I remove the "user proxy" additions from the rule set I showed, it works just perfect. I'll try to investigate why "user proxy" does not work, because when I check with ps ftp-proxy is clearly running as user proxy. Cheers, Martin From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 22:47:01 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE3016A4CE for ; Mon, 24 Jan 2005 22:47:01 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 414AC43D31 for ; Mon, 24 Jan 2005 22:47:01 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id C84E8BC17B; Tue, 25 Jan 2005 00:46:59 +0200 (EET) Received: from R3B (vdp3061.ath03.dsl.hol.gr [62.38.162.62])by smtp.freemail.gr (Postfix) with ESMTP id A877EBC152for ; Tue, 25 Jan 2005 00:46:58 +0200 (EET) Message-ID: <002301c50266$74952ba0$0100000a@R3B> From: "Chris Dionissopoulos" To: References: Date: Tue, 25 Jan 2005 00:45:49 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-7"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 22:47:02 -0000 try this one: set state-policy if-bound lan = ext_if1 = ext_if2 = gw1 = gw2 = 1 = "(" $ext_if1 $gw1 ")" 2 = "(" $ext_if2 $gw2 ")" nat on $ext_if1 from $internal_net to any -> ($ext_if1) nat on $ext_if2 from $internal_net to any -> ($ext_if2) #local pass in quick on $lan inet from $lan:network to $lan keep state pass out quick on $lan inet from $lan to $lan:network keep state #wans pass in on $ext_if1 tag $ext_if1 keep state pass out on $lan reply-to $1 tagged $ext_if1 keep state pass in on $ext_if2 tag $ext_if2 keep state pass out on $lan reply-to $2 tagged $ext_if2 keep state # balance pass in on $lan route-to { $0 $1 } round-robin keep state #OUT pass out on $ext_if1 route-to $0 keep state pass out on $ext_if1 route-to $1 keep state and tell us if worked for you. Chris. ----- Original Message ----- From: "Stephane Raimbault" To: Sent: Tuesday, January 25, 2005 12:24 AM Subject: route-to rule. >I have a freebsd box with 2 wan interfaces, 1 lan interface and 1 tun >interface. > > I have pf setup so that 10.1.0.64/26 and 10.1.0.128/25 go out our second > wan interface like this: > > nat on $ext_if1 from $internal_net to any -> ($ext_if1) > nat on $ext_if2 from $internal_net to any -> ($ext_if2) > > pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , > 10.1.0.128/25 } to any > > pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any > pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any > > > However, any traffic destined to 10.0.0.0/26 accessible via the tun0 > interface doesn't get routed as I'm guessing it goes out to the 2nd wan > interface ( $ext_if2 ). > > I've tried modifying the pass in line like this: > > pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , > 10.1.0.128/25 } to { 0.0.0.0/0, !10.0.0.0/26 } > > However it did not work. Any suggestions on this? > > thanks, > stephane. > > _________________________________________________________________ > Take charge with a pop-up guard built on patented Microsoft® SmartScreen > Technology. > http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines > Start enjoying all the benefits of MSN® Premium right now and get the > first two months FREE*. > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 23:15:47 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 289F316A4CE for ; Mon, 24 Jan 2005 23:15:47 +0000 (GMT) Received: from brugere.aub.dk (fw.aub.dk [195.24.1.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C756E43D2F for ; Mon, 24 Jan 2005 23:15:46 +0000 (GMT) (envelope-from techlists@motrix.dk) Received: by brugere.aub.dk (Postfix, from userid 1693) id DC658C47B; Tue, 25 Jan 2005 00:15:45 +0100 (CET) Received: from [10.1.4.50] (jmp.aub.dk [10.1.4.50]) by brugere.aub.dk (Postfix) with ESMTP id C2E4EC43B for ; Tue, 25 Jan 2005 00:15:45 +0100 (CET) Message-ID: <41F581A1.90605@motrix.dk> Date: Tue, 25 Jan 2005 00:15:45 +0100 From: "J. Martin Petersen" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <41F3F039.1060101@motrix.dk> <41F577FA.7090300@motrix.dk> In-Reply-To: <41F577FA.7090300@motrix.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems with ftp/ftp-proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 23:15:47 -0000 J. Martin Petersen wrote: > Ah, thanks for the tip. When I remove the "user proxy" additions from > the rule set I showed, it works just perfect. I'll try to investigate > why "user proxy" does not work, because when I check with ps ftp-proxy > is clearly running as user proxy. It seems I spoke too soon. After some fiddling around it actually seems to work with "user proxy". What does not, however, "just work" is active ftp from a pc running Windows XP sp2 with the built-in firewall enabled. What fooled me was that while it is perfectly capable of connecting to a machine on the local network with active ftp and the firewall turned on, it does not work when you try to connect to an external server with active ftp as the XP firewall drops the return packages from the ftp-proxy after the PORT command. I can't understand why, but it seems to be well known that the XP firewall does all sorts of weird stuff to ftp clients. Sigh. Cheers, Martin. From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 23:44:02 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46A8016A4CE for ; Mon, 24 Jan 2005 23:44:02 +0000 (GMT) Received: from hotmail.com (bay24-f8.bay24.hotmail.com [64.4.18.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2EDA43D49 for ; Mon, 24 Jan 2005 23:44:01 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Jan 2005 15:44:01 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Mon, 24 Jan 2005 23:43:59 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: freebsd-pf@freebsd.org Date: Mon, 24 Jan 2005 16:43:59 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Jan 2005 23:44:01.0020 (UTC) FILETIME=[9473C3C0:01C5026E] Subject: RE: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 23:44:02 -0000 Hi, I also have some binat's setup for some servers, however they are only on one interface... Can I simply add these binat rules to the the suggested pf.conf file? binat on $ext_if1 from $server1_int to any -> $server1_out binat on $ext_if1 from $server2_int to any -> $server2_out where server?_int = internal IP and server?_out = public IP? Thanks, Stephane. ---------- try this one: set state-policy if-bound lan = ext_if1 = ext_if2 = gw1 = gw2 = 1 = "(" $ext_if1 $gw1 ")" 2 = "(" $ext_if2 $gw2 ")" nat on $ext_if1 from $internal_net to any -> ($ext_if1) nat on $ext_if2 from $internal_net to any -> ($ext_if2) #local pass in quick on $lan inet from $lan:network to $lan keep state pass out quick on $lan inet from $lan to $lan:network keep state #wans pass in on $ext_if1 tag $ext_if1 keep state pass out on $lan reply-to $1 tagged $ext_if1 keep state pass in on $ext_if2 tag $ext_if2 keep state pass out on $lan reply-to $2 tagged $ext_if2 keep state # balance pass in on $lan route-to { $0 $1 } round-robin keep state #OUT pass out on $ext_if1 route-to $0 keep state pass out on $ext_if1 route-to $1 keep state and tell us if worked for you. Chris. ----- Original Message ----- From: "Stephane Raimbault" To: Sent: Tuesday, January 25, 2005 12:24 AM Subject: route-to rule. >I have a freebsd box with 2 wan interfaces, 1 lan interface and 1 tun >interface. > >I have pf setup so that 10.1.0.64/26 and 10.1.0.128/25 go out our second >wan interface like this: > >nat on $ext_if1 from $internal_net to any -> ($ext_if1) >nat on $ext_if2 from $internal_net to any -> ($ext_if2) > >pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , >10.1.0.128/25 } to any > >pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any >pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any > > >However, any traffic destined to 10.0.0.0/26 accessible via the tun0 >interface doesn't get routed as I'm guessing it goes out to the 2nd wan >interface ( $ext_if2 ). > >I've tried modifying the pass in line like this: > >pass in on $int_if route-to ($ext_if2 $ext_gw2) from { 10.1.0.64/26 , >10.1.0.128/25 } to { 0.0.0.0/0, !10.0.0.0/26 } > >However it did not work. Any suggestions on this? > >thanks, >stephane. > >_________________________________________________________________ >Take charge with a pop-up guard built on patented Microsoft® SmartScreen >Technology. >http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines >Start enjoying all the benefits of MSN® Premium right now and get the first >two months FREE*. > >_______________________________________________ >freebsd-pf at freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org" _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Mon Jan 24 23:51:55 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90C6B16A4CE for ; Mon, 24 Jan 2005 23:51:55 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F6143D39 for ; Mon, 24 Jan 2005 23:51:55 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 63F8EBC164; Tue, 25 Jan 2005 01:51:54 +0200 (EET) Received: from R3B (vdp3061.ath03.dsl.hol.gr [62.38.162.62])by smtp.freemail.gr (Postfix) with ESMTP id 930A6BC155for ; Tue, 25 Jan 2005 01:51:53 +0200 (EET) Message-ID: <004701c5026f$825b15c0$0100000a@R3B> From: "Chris Dionissopoulos" To: References: Date: Tue, 25 Jan 2005 01:50:38 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-7"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2005 23:51:55 -0000 Yes. You can do binat on one or both interfaces, the same or different source ip address. Please test it and send us a feedback. Chris. ----- Original Message ----- From: "Stephane Raimbault" To: Cc: Sent: Tuesday, January 25, 2005 1:43 AM Subject: RE: route-to rule. > Hi, I also have some binat's setup for some servers, however they are only > on one interface... Can I simply add these binat rules to the the > suggested pf.conf file? > > binat on $ext_if1 from $server1_int to any -> $server1_out > binat on $ext_if1 from $server2_int to any -> $server2_out > > where server?_int = internal IP and server?_out = public IP? > ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 04:35:05 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CDE416A4CE for ; Tue, 25 Jan 2005 04:35:05 +0000 (GMT) Received: from mail.3gne.com (ded191-fbsd-174-39.netsonic.net [66.180.174.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED48943D58 for ; Tue, 25 Jan 2005 04:35:02 +0000 (GMT) (envelope-from nick@buraglio.com) Received: from localhost (localhost.3gne.com [127.0.0.1]) by mail.3gne.com (Postfix) with ESMTP id 4A954D5635 for ; Mon, 24 Jan 2005 22:41:03 -0600 (CST) Received: from [192.168.100.243] (12-221-108-48.client.insightBB.com [12.221.108.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.3gne.com (Postfix) with ESMTP id 5D9B5D544F for ; Mon, 24 Jan 2005 22:41:00 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <8B6F7B50-6E8A-11D9-98FB-000393B61F2E@buraglio.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-pf@freebsd.org From: Nick Buraglio Date: Mon, 24 Jan 2005 22:35:30 -0600 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at 3gne.com Subject: pftabled X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 04:35:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone gotten pftabled ( http://www.wolfermann.org/pftabled.html )to compile on freebsd 5.3? I find it immensely useful under openbsd for managing tables but under free it bombs with pftabled.c:53: error: variable `sdata' has initializer but incomplete type I don't really know c, but I think it means that there is something defined in a struct that isn't being found where it's expected. This is kinda off topic, but any help on or off list appreciated. In the meantime I'm going to try and brush up on C. ./configure works fine (although says it's building on openbsd) make yields this: gcc -g -O2 -Wall -c pftabled.c pftabled.c:53: error: variable `sdata' has initializer but incomplete type pftabled.c:53: error: `SYSLOG_DATA_INIT' undeclared here (not in a function) pftabled.c: In function `logit': pftabled.c:73: error: invalid use of undefined type `struct syslog_data' pftabled.c:74: warning: implicit declaration of function `vsyslog_r' pftabled.c: In function `main': pftabled.c:267: warning: implicit declaration of function `openlog_r' pftabled.c: At top level: pftabled.c:53: error: storage size of `sdata' isn't known *** Error code 1 Stop in /usr/home/buraglio/pftabled-1.04. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB9cyVFOm2Sy5bRPQRArw9AJ9A6Yef1MVOxoENqI01TPl4/y+0vQCfdIts 1h54FopatHc6sGZ25Pp7YGc= =HPRN -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 07:36:43 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C35916A4CE for ; Tue, 25 Jan 2005 07:36:43 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 443B043D39 for ; Tue, 25 Jan 2005 07:36:42 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j0P7acSK011614 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2005 08:36:38 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.2/8.12.10/Submit) id j0P7abUE016638; Tue, 25 Jan 2005 08:36:37 +0100 (MET) Date: Tue, 25 Jan 2005 08:36:37 +0100 From: Daniel Hartmeier To: Nick Buraglio Message-ID: <20050125073637.GF7366@insomnia.benzedrine.cx> References: <8B6F7B50-6E8A-11D9-98FB-000393B61F2E@buraglio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B6F7B50-6E8A-11D9-98FB-000393B61F2E@buraglio.com> User-Agent: Mutt/1.4.1i cc: freebsd-pf@freebsd.org Subject: Re: pftabled X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 07:36:43 -0000 On Mon, Jan 24, 2005 at 10:35:30PM -0600, Nick Buraglio wrote: > Anyone gotten pftabled ( http://www.wolfermann.org/pftabled.html )to > compile on freebsd 5.3? I find it immensely useful under openbsd for > managing tables but under free it bombs with > > pftabled.c:53: error: variable `sdata' has initializer but incomplete > type > > I don't really know c, but I think it means that there is something > defined in a struct that isn't being found where it's expected. It's using the reentrant syslog functions from OpenBSD. Since they're not called from a signal handler, that's not really needed. You can just switch to the standard versions with the patch below, which builds on FreeBSD 5.3. Daniel --- ../pftabled-1.04.orig/pftabled.c Sun Sep 12 17:53:22 2004 +++ pftabled.c Tue Jan 25 08:37:02 2005 @@ -50,7 +50,7 @@ #define PFDEV "/dev/pf" static int pfdev = -1; -static struct syslog_data sdata = SYSLOG_DATA_INIT; +static int daemonize = 0; static int timeout = 0; @@ -70,8 +70,8 @@ va_start(ap, fmt); - if (sdata.opened) { - vsyslog_r(level, &sdata, fmt, ap); + if (daemonize) { + vsyslog(level, fmt, ap); } else { fprintf(stderr, "%s: ", __progname); vfprintf(stderr, fmt, ap); @@ -194,7 +194,6 @@ /* Options and their defaults */ char *address = NULL; - int daemonize = 0; char *forced = NULL; char key[SHA1_DIGEST_LENGTH]; int port = 56789; @@ -264,7 +263,6 @@ /* Daemonize if requested */ if (daemonize) { tzset(); - openlog_r("pftabled", LOG_PID|LOG_NDELAY, LOG_DAEMON, &sdata); if (daemon(0, 0) == -1) err(1, "daemon"); From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 15:36:28 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79A8916A4CE for ; Tue, 25 Jan 2005 15:36:28 +0000 (GMT) Received: from mail.3gne.com (ded191-fbsd-174-39.netsonic.net [66.180.174.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218B143D3F for ; Tue, 25 Jan 2005 15:36:28 +0000 (GMT) (envelope-from nick@buraglio.com) Received: from localhost (localhost.3gne.com [127.0.0.1]) by mail.3gne.com (Postfix) with ESMTP id A35D1D434B; Tue, 25 Jan 2005 09:42:28 -0600 (CST) Received: from [141.142.102.193] (cab-wireless-193.ncsa.uiuc.edu [141.142.102.193]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.3gne.com (Postfix) with ESMTP id 68F46D431F; Tue, 25 Jan 2005 09:42:25 -0600 (CST) In-Reply-To: <20050125073637.GF7366@insomnia.benzedrine.cx> References: <8B6F7B50-6E8A-11D9-98FB-000393B61F2E@buraglio.com> <20050125073637.GF7366@insomnia.benzedrine.cx> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Nick Buraglio Date: Tue, 25 Jan 2005 09:36:58 -0600 To: Daniel Hartmeier X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at 3gne.com cc: freebsd-pf@freebsd.org Subject: Re: pftabled X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 15:36:28 -0000 Excellent. Thanks. The author also provided a patch, which I tested as good on freebsd 5.3. Thanks again for the quick responses! nb --- pftabled.c.orig Tue Jan 25 09:26:16 2005 +++ pftabled.c Tue Jan 25 09:28:37 2005 @@ -50,7 +50,11 @@ #define PFDEV "/dev/pf" static int pfdev = -1; +#ifdef __FreeBSD__ +static int use_syslog = 0; +#else static struct syslog_data sdata = SYSLOG_DATA_INIT; +#endif static int timeout = 0; @@ -70,8 +74,13 @@ va_start(ap, fmt); +#ifdef __FreeBSD__ + if (use_syslog) { + vsyslog(level, fmt, ap); +#else if (sdata.opened) { vsyslog_r(level, &sdata, fmt, ap); +#endif } else { fprintf(stderr, "%s: ", __progname); vfprintf(stderr, fmt, ap); @@ -264,7 +273,11 @@ /* Daemonize if requested */ if (daemonize) { tzset(); +#ifdef __FreeBSD__ + use_syslog = 1; +#else openlog_r("pftabled", LOG_PID|LOG_NDELAY, LOG_DAEMON, &sdata); +#endif if (daemon(0, 0) == -1) err(1, "daemon"); ------------ - Nick Buraglio, Network Engineer, NCSA - Phone: 217.244.6428 - GnuPG Key: 0x2E5B44F4 ------------ On Jan 25, 2005, at 1:36 AM, Daniel Hartmeier wrote: > On Mon, Jan 24, 2005 at 10:35:30PM -0600, Nick Buraglio wrote: > >> Anyone gotten pftabled ( http://www.wolfermann.org/pftabled.html )to >> compile on freebsd 5.3? I find it immensely useful under openbsd for >> managing tables but under free it bombs with >> >> pftabled.c:53: error: variable `sdata' has initializer but incomplete >> type >> >> I don't really know c, but I think it means that there is something >> defined in a struct that isn't being found where it's expected. > > It's using the reentrant syslog functions from OpenBSD. Since they're > not called from a signal handler, that's not really needed. You can > just > switch to the standard versions with the patch below, which builds on > FreeBSD 5.3. > > Daniel > > > --- ../pftabled-1.04.orig/pftabled.c Sun Sep 12 17:53:22 2004 > +++ pftabled.c Tue Jan 25 08:37:02 2005 > @@ -50,7 +50,7 @@ > #define PFDEV "/dev/pf" > static int pfdev = -1; > > -static struct syslog_data sdata = SYSLOG_DATA_INIT; > +static int daemonize = 0; > > static int timeout = 0; > > @@ -70,8 +70,8 @@ > > va_start(ap, fmt); > > - if (sdata.opened) { > - vsyslog_r(level, &sdata, fmt, ap); > + if (daemonize) { > + vsyslog(level, fmt, ap); > } else { > fprintf(stderr, "%s: ", __progname); > vfprintf(stderr, fmt, ap); > @@ -194,7 +194,6 @@ > > /* Options and their defaults */ > char *address = NULL; > - int daemonize = 0; > char *forced = NULL; > char key[SHA1_DIGEST_LENGTH]; > int port = 56789; > @@ -264,7 +263,6 @@ > /* Daemonize if requested */ > if (daemonize) { > tzset(); > - openlog_r("pftabled", LOG_PID|LOG_NDELAY, LOG_DAEMON, &sdata); > > if (daemon(0, 0) == -1) > err(1, "daemon"); From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 16:56:20 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BCBF16A4D4 for ; Tue, 25 Jan 2005 16:56:20 +0000 (GMT) Received: from hotmail.com (bay24-f38.bay24.hotmail.com [64.4.18.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E03443D31 for ; Tue, 25 Jan 2005 16:56:20 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jan 2005 08:56:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 25 Jan 2005 16:55:19 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <004701c5026f$825b15c0$0100000a@R3B> From: "Stephane Raimbault" To: dionch@freemail.gr, freebsd-pf@freebsd.org Date: Tue, 25 Jan 2005 09:55:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jan 2005 16:56:02.0023 (UTC) FILETIME=[C03EFF70:01C502FE] Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 16:56:20 -0000 Okay, I gave this a try and this is what I saw. lan traffic was being load balanced over the wan interfaces binat traffic seemed to be working over one of the wan interfaces as intended. however tun0 (vpn traffic) was not working from the internal_lan. I could ping across the tun0 from the pf box, but the lan couldn't get across it. So I need to try to figure that part out, also lan traffic does not have to be load balanced across the 2 wan interfaces, but I'm guessing I just need ot specify that in the balance part? I removed the binat lines but this is what I have in my pf.conf now: set state-policy if-bound lan = rl0 ext_if1 = rl1 ext_if2 = rl2 gw1 = gw2 = 1 = "(" $ext_if1 $gw1 ")" 2 = "(" $ext_if2 $gw2 ")" internal_net="10.1.0.0/24" nat on $ext_if1 from $internal_net to any -> ($ext_if1) nat on $ext_if2 from $internal_net to any -> ($ext_if2) #local pass in quick on $lan inet from $lan:network to $lan keep state pass out quick on $lan inet from $lan to $lan:network keep state #wans pass in on $ext_if1 tag $ext_if1 keep state pass out on $lan reply-to $1 tagged $ext_if1 keep state pass in on $ext_if2 tag $ext_if2 keep state pass out on $lan reply-to $2 tagged $ext_if2 keep state # balance pass in on $lan route-to { $1 $2 } round-robin keep state #OUT pass out on $ext_if1 route-to $1 keep state pass out on $ext_if1 route-to $2 keep state Any further Suggestions? Thanks, Stephane. >From: "Chris Dionissopoulos" >Reply-To: Chris Dionissopoulos >To: >Subject: Re: route-to rule. >Date: Tue, 25 Jan 2005 01:50:38 +0200 > >Yes. You can do binat on one or both interfaces, >the same or different source ip address. >Please test it and send us a feedback. > >Chris. > >----- Original Message ----- From: "Stephane Raimbault" >To: >Cc: >Sent: Tuesday, January 25, 2005 1:43 AM >Subject: RE: route-to rule. > > >>Hi, I also have some binat's setup for some servers, however they are only >>on one interface... Can I simply add these binat rules to the the >>suggested pf.conf file? >> >>binat on $ext_if1 from $server1_int to any -> $server1_out >>binat on $ext_if1 from $server2_int to any -> $server2_out >> >>where server?_int = internal IP and server?_out = public IP? >> > > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. >_______________________________________________ >freebsd-pf@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 17:18:37 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6527C16A4CE for ; Tue, 25 Jan 2005 17:18:37 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA7C043D48 for ; Tue, 25 Jan 2005 17:18:36 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 8566DBC1E6; Tue, 25 Jan 2005 19:18:35 +0200 (EET) Received: from R3B (vdp3061.ath03.dsl.hol.gr [62.38.162.62])by smtp.freemail.gr (Postfix) with ESMTP id DF2ECBC103;Tue, 25 Jan 2005 19:18:33 +0200 (EET) Message-ID: <004a01c50301$b82c2a80$0100000a@R3B> From: "Chris Dionissopoulos" To: "Stephane Raimbault" , References: Date: Tue, 25 Jan 2005 19:17:13 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-7"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 17:18:37 -0000 Sorry my fault, I didnt notice your 4th interface. Try this one: --------------pf.conf------------- set state-policy if-bound #MACROS lan = rl0 ext_if1 = rl1 ext_if2 = rl2 vpn_if = tun0 vpn_net = gw1 = gw2 = vpn_gw = 1 = "(" $ext_if1 $gw1 ")" 2 = "(" $ext_if2 $gw2 ")" vpn = "(" $vpn_if $vpn_gw ")" #NAT nat on $ext_if1 from $internal_net to any -> ($ext_if1) nat on $ext_if2 from $internal_net to any -> ($ext_if2) #RULES #local lan pass in quick on $lan inet from $lan:network to $lan keep state pass out quick on $lan inet from $lan to $lan:network keep state #wan(s) and vpn pass in on $ext_if1 tag $ext_if1 keep state pass out on $lan reply-to $1 tagged $ext_if1 keep state pass in on $ext_if2 tag $ext_if2 keep state pass out on $lan reply-to $2 tagged $ext_if2 keep state pass in on $vpn_if tag $vpn_if keep state pass out on $lan reply-to $vpn tagged $vpn_if keep state # balance pass in on $lan route-to { $1 $2 } round-robin keep state pass in on $lan route-to { $vpn } from $lan:network to $vpn_net keep state #OUT pass out on $ext_if1 route-to $1 keep state pass out on $ext_if1 route-to $2 keep state pass out on $vpn_if route-to $vpn keep state ---------------------------- This works? Chris. ----- Original Message ----- From: "Stephane Raimbault" To: ; Sent: Tuesday, January 25, 2005 6:55 PM Subject: Re: route-to rule. > Okay, I gave this a try and this is what I saw. > > lan traffic was being load balanced over the wan interfaces > binat traffic seemed to be working over one of the wan interfaces as > intended. > however tun0 (vpn traffic) was not working from the internal_lan. > > I could ping across the tun0 from the pf box, but the lan couldn't get > across it. > > So I need to try to figure that part out, also lan traffic does not have > to be load balanced across the 2 wan interfaces, but I'm guessing I just > need ot specify that in the balance part? I removed the binat lines but > this is what I have in my pf.conf now: > > set state-policy if-bound > > lan = rl0 > ext_if1 = rl1 > ext_if2 = rl2 > gw1 = > gw2 = > > 1 = "(" $ext_if1 $gw1 ")" > 2 = "(" $ext_if2 $gw2 ")" > > internal_net="10.1.0.0/24" > > nat on $ext_if1 from $internal_net to any -> ($ext_if1) > nat on $ext_if2 from $internal_net to any -> ($ext_if2) > > #local > pass in quick on $lan inet from $lan:network to $lan keep state > pass out quick on $lan inet from $lan to $lan:network keep state > > #wans > pass in on $ext_if1 tag $ext_if1 keep state > pass out on $lan reply-to $1 tagged $ext_if1 keep state > > pass in on $ext_if2 tag $ext_if2 keep state > pass out on $lan reply-to $2 tagged $ext_if2 keep state > > # balance > pass in on $lan route-to { $1 $2 } round-robin keep state > > #OUT > pass out on $ext_if1 route-to $1 keep state > pass out on $ext_if1 route-to $2 keep state > > > > Any further Suggestions? > ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 18:18:09 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFAA216A4CE for ; Tue, 25 Jan 2005 18:18:08 +0000 (GMT) Received: from hotmail.com (bay24-f2.bay24.hotmail.com [64.4.18.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8878343D5C for ; Tue, 25 Jan 2005 18:18:08 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jan 2005 10:18:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 25 Jan 2005 18:17:00 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <004a01c50301$b82c2a80$0100000a@R3B> From: "Stephane Raimbault" To: dionch@freemail.gr, freebsd-pf@freebsd.org Date: Tue, 25 Jan 2005 11:17:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jan 2005 18:18:02.0142 (UTC) FILETIME=[34DD93E0:01C5030A] Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 18:18:09 -0000 Well this is odd.. I gave this a try... and the tun interface wasn't able to pass traffic between the 2 lan's 10.0.0.0/26 is the remote lan, and 10.1.0.0/24 is the local lan. and dns stopped working for the local lan... I have a caching dns server configured on the pf box, and even that couldn't resolve anything despite still having good network connections to the 2 wan's Any idea what's missing? Thanks, sTephane. >From: "Chris Dionissopoulos" >Reply-To: "Chris Dionissopoulos" >To: "Stephane Raimbault" , >Subject: Re: route-to rule. >Date: Tue, 25 Jan 2005 19:17:13 +0200 > >Sorry my fault, I didnt notice your 4th interface. >Try this one: >--------------pf.conf------------- >set state-policy if-bound > >#MACROS > >lan = rl0 >ext_if1 = rl1 >ext_if2 = rl2 >vpn_if = tun0 > >vpn_net = >gw1 = >gw2 = >vpn_gw = > >1 = "(" $ext_if1 $gw1 ")" >2 = "(" $ext_if2 $gw2 ")" >vpn = "(" $vpn_if $vpn_gw ")" > >#NAT >nat on $ext_if1 from $internal_net to any -> ($ext_if1) >nat on $ext_if2 from $internal_net to any -> ($ext_if2) > >#RULES >#local lan >pass in quick on $lan inet from $lan:network to $lan keep state >pass out quick on $lan inet from $lan to $lan:network keep state > >#wan(s) and vpn >pass in on $ext_if1 tag $ext_if1 keep state >pass out on $lan reply-to $1 tagged $ext_if1 keep state > >pass in on $ext_if2 tag $ext_if2 keep state >pass out on $lan reply-to $2 tagged $ext_if2 keep state > >pass in on $vpn_if tag $vpn_if keep state >pass out on $lan reply-to $vpn tagged $vpn_if keep state > ># balance >pass in on $lan route-to { $1 $2 } round-robin keep state >pass in on $lan route-to { $vpn } from $lan:network to $vpn_net keep state > >#OUT >pass out on $ext_if1 route-to $1 keep state >pass out on $ext_if1 route-to $2 keep state >pass out on $vpn_if route-to $vpn keep state >---------------------------- > > >This works? > >Chris. > >----- Original Message ----- From: "Stephane Raimbault" >To: ; >Sent: Tuesday, January 25, 2005 6:55 PM >Subject: Re: route-to rule. > > >>Okay, I gave this a try and this is what I saw. >> >>lan traffic was being load balanced over the wan interfaces >>binat traffic seemed to be working over one of the wan interfaces as >>intended. >>however tun0 (vpn traffic) was not working from the internal_lan. >> >>I could ping across the tun0 from the pf box, but the lan couldn't get >>across it. >> >>So I need to try to figure that part out, also lan traffic does not have >>to be load balanced across the 2 wan interfaces, but I'm guessing I just >>need ot specify that in the balance part? I removed the binat lines but >>this is what I have in my pf.conf now: >> >>set state-policy if-bound >> >>lan = rl0 >>ext_if1 = rl1 >>ext_if2 = rl2 >>gw1 = >>gw2 = >> >>1 = "(" $ext_if1 $gw1 ")" >>2 = "(" $ext_if2 $gw2 ")" >> >>internal_net="10.1.0.0/24" >> >>nat on $ext_if1 from $internal_net to any -> ($ext_if1) >>nat on $ext_if2 from $internal_net to any -> ($ext_if2) >> >>#local >>pass in quick on $lan inet from $lan:network to $lan keep state >>pass out quick on $lan inet from $lan to $lan:network keep state >> >>#wans >>pass in on $ext_if1 tag $ext_if1 keep state >>pass out on $lan reply-to $1 tagged $ext_if1 keep state >> >>pass in on $ext_if2 tag $ext_if2 keep state >>pass out on $lan reply-to $2 tagged $ext_if2 keep state >> >># balance >>pass in on $lan route-to { $1 $2 } round-robin keep state >> >>#OUT >>pass out on $ext_if1 route-to $1 keep state >>pass out on $ext_if1 route-to $2 keep state >> >> >> >>Any further Suggestions? >> > > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 18:44:42 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B1A016A4CE for ; Tue, 25 Jan 2005 18:44:42 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1BDB43D2F for ; Tue, 25 Jan 2005 18:44:41 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id B2781BC103; Tue, 25 Jan 2005 20:44:40 +0200 (EET) Received: from R3B (vdp3061.ath03.dsl.hol.gr [62.38.162.62])by smtp.freemail.gr (Postfix) with ESMTP id BB1CABC04A;Tue, 25 Jan 2005 20:44:38 +0200 (EET) Message-ID: <005101c5030d$b98beb20$0100000a@R3B> From: "Chris Dionissopoulos" To: "Stephane Raimbault" , References: Date: Tue, 25 Jan 2005 20:43:09 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-7"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 18:44:42 -0000 Hi, For vpn problem: Is routing already set in both sides? pf-box: route add 10.0.0.0/26 Other vpn end: route add 10.0.1.0/24 For DNS problem: You have to decide which gateway pf-box will use as default for own connections (default gateway is missing). route add default | maybe solves it. Chris. ----- Original Message ----- From: "Stephane Raimbault" To: ; Sent: Tuesday, January 25, 2005 8:17 PM Subject: Re: route-to rule. > Well this is odd.. I gave this a try... and the tun interface wasn't able > to pass traffic between the 2 lan's > > 10.0.0.0/26 is the remote lan, and 10.1.0.0/24 is the local lan. > > and dns stopped working for the local lan... I have a caching dns server > configured on the pf box, and even that couldn't resolve anything despite > still having good network connections to the 2 wan's > > Any idea what's missing? > > Thanks, > sTephane. > ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 20:04:09 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0654E16A4CE for ; Tue, 25 Jan 2005 20:04:09 +0000 (GMT) Received: from hotmail.com (bay24-f18.bay24.hotmail.com [64.4.18.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6E8043D5C for ; Tue, 25 Jan 2005 20:04:08 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jan 2005 12:04:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 25 Jan 2005 20:03:58 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <005101c5030d$b98beb20$0100000a@R3B> From: "Stephane Raimbault" To: dionch@freemail.gr, freebsd-pf@freebsd.org Date: Tue, 25 Jan 2005 13:03:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jan 2005 20:04:02.0471 (UTC) FILETIME=[03EAC370:01C50319] Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 20:04:09 -0000 Hi chris, Thanks for all your help btw :) Okay, so I have my vpn routes and default routes setup already.... so I tried the config earlier today without the tun interfaces you suggested yesterday... and sure enough, once I put that in, I couldn't do dns lookups... I hadn't noticed it this morning cuz I only looked up already cached dns queries. So something in this configuration is stopping dns (possible udp?) packets? the pf box, seems to respond from the wan interfaces just fine and people are able to surf to sites previously cached in dns. This is become a bit of a head scratcher. Also, pinging the 10.1.0.0/24 and 10.0.0.0/26 LAN's stop once I put in the configuration you suggested, or even whith the tun interfaces in the configuration it stops pinging. so somewhere we are going ary. Any thoughts? Thanks, Stephane. >From: "Chris Dionissopoulos" >Reply-To: "Chris Dionissopoulos" >To: "Stephane Raimbault" , >Subject: Re: route-to rule. >Date: Tue, 25 Jan 2005 20:43:09 +0200 > >Hi, > >For vpn problem: >Is routing already set in both sides? > >pf-box: >route add 10.0.0.0/26 > >Other vpn end: >route add 10.0.1.0/24 > > >For DNS problem: >You have to decide which gateway pf-box will use >as default for own connections (default gateway is missing). >route add default | maybe solves it. > >Chris. > > > >----- Original Message ----- From: "Stephane Raimbault" >To: ; >Sent: Tuesday, January 25, 2005 8:17 PM >Subject: Re: route-to rule. > > >>Well this is odd.. I gave this a try... and the tun interface wasn't able >>to pass traffic between the 2 lan's >> >>10.0.0.0/26 is the remote lan, and 10.1.0.0/24 is the local lan. >> >>and dns stopped working for the local lan... I have a caching dns server >>configured on the pf box, and even that couldn't resolve anything despite >>still having good network connections to the 2 wan's >> >>Any idea what's missing? >> >>Thanks, >>sTephane. >> > > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 23:23:03 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2D9116A4CE for ; Tue, 25 Jan 2005 23:23:03 +0000 (GMT) Received: from hotmail.com (bay24-f7.bay24.hotmail.com [64.4.18.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91DE943D53 for ; Tue, 25 Jan 2005 23:23:03 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jan 2005 15:23:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 25 Jan 2005 23:22:45 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <005101c5030d$b98beb20$0100000a@R3B> From: "Stephane Raimbault" To: dionch@freemail.gr, freebsd-pf@freebsd.org Date: Tue, 25 Jan 2005 16:22:45 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jan 2005 23:23:02.0757 (UTC) FILETIME=[D0E1D150:01C50334] Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 23:23:03 -0000 Looking into audities... it seems that the nat that goes across this line right now: nat on $ext_if1 from $internal_net to any -> ($ext_if1) seems to round robin the external IP as I have several IP's aliased on $ext_if1 if I replace the above line with this: nat on $ext_if1 from $internal_net to any -> ($ext_ip1) where $ext_ip1 is the external IP I want the nat to go out, however when I do this... the lan can no longer establish new connections... any thoughts on this? Thanks, Stephane. >From: "Chris Dionissopoulos" >Reply-To: "Chris Dionissopoulos" >To: "Stephane Raimbault" , >Subject: Re: route-to rule. >Date: Tue, 25 Jan 2005 20:43:09 +0200 > >Hi, > >For vpn problem: >Is routing already set in both sides? > >pf-box: >route add 10.0.0.0/26 > >Other vpn end: >route add 10.0.1.0/24 > > >For DNS problem: >You have to decide which gateway pf-box will use >as default for own connections (default gateway is missing). >route add default | maybe solves it. > >Chris. > > > >----- Original Message ----- From: "Stephane Raimbault" >To: ; >Sent: Tuesday, January 25, 2005 8:17 PM >Subject: Re: route-to rule. > > >>Well this is odd.. I gave this a try... and the tun interface wasn't able >>to pass traffic between the 2 lan's >> >>10.0.0.0/26 is the remote lan, and 10.1.0.0/24 is the local lan. >> >>and dns stopped working for the local lan... I have a caching dns server >>configured on the pf box, and even that couldn't resolve anything despite >>still having good network connections to the 2 wan's >> >>Any idea what's missing? >> >>Thanks, >>sTephane. >> > > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 25 23:45:19 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DBCE16A4CE for ; Tue, 25 Jan 2005 23:45:19 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F03243D31 for ; Tue, 25 Jan 2005 23:45:18 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j0PNjGQ8022519 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2005 00:45:16 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.2/8.12.10/Submit) id j0PNjF0F010414; Wed, 26 Jan 2005 00:45:15 +0100 (MET) Date: Wed, 26 Jan 2005 00:45:13 +0100 From: Daniel Hartmeier To: Stephane Raimbault Message-ID: <20050125234513.GH17646@insomnia.benzedrine.cx> References: <005101c5030d$b98beb20$0100000a@R3B> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-pf@freebsd.org Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 23:45:19 -0000 On Tue, Jan 25, 2005 at 04:22:45PM -0700, Stephane Raimbault wrote: > Looking into audities... it seems that the nat that goes across this line > right now: > > nat on $ext_if1 from $internal_net to any -> ($ext_if1) > > seems to round robin the external IP as I have several IP's aliased on > $ext_if1 if I replace the above line with this: > > nat on $ext_if1 from $internal_net to any -> ($ext_ip1) > > where $ext_ip1 is the external IP I want the nat to go out, however when I > do this... the lan can no longer establish new connections... any thoughts > on this? You can put () around an interface name, meaning 'dynamic interface name to address translation'. In the first example, as you noted, this means pf will round-robin through all addresses of the interface to pick a source address for NATed connections. The second example makes no sense. If what you want is to use a constant source address for NAT, just use -> $ext_ip1 without the parentheses. If you expect $ext_if1 to change its address dynamically, and you want to use its 'main' address as replacement (but not round-robin through aliases, if it has any), use -> ($ext_if1:0) If you want still something else, please explain. What you actually have in your second example is (surprisingly) not a syntax error, but -> (10.1.2.3) Which means the interface with name "10.1.2.3". There is no such interface, of course, but since pf accepts non-existant interfaces (which could exist later on, think USB or PCMCIA nics), it accepts this. It's still non-sensical, don't use () around IP addresses. :) Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jan 26 16:42:08 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8ED16A4CE for ; Wed, 26 Jan 2005 16:42:08 +0000 (GMT) Received: from hotmail.com (bay24-f29.bay24.hotmail.com [64.4.18.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 531B743D2F for ; Wed, 26 Jan 2005 16:42:08 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Jan 2005 08:42:06 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Wed, 26 Jan 2005 16:41:42 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <20050125234513.GH17646@insomnia.benzedrine.cx> From: "Stephane Raimbault" To: daniel@benzedrine.cx Date: Wed, 26 Jan 2005 09:41:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jan 2005 16:42:06.0168 (UTC) FILETIME=[F8736580:01C503C5] cc: freebsd-pf@freebsd.org Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2005 16:42:08 -0000 Well this made a lot of sense.. thanks for the info, and now I've resolved that problem... so to recap my situation. I have a FreeBSD-pf box with the following interfaces: rl0 - Internal lan (10.1.0.0/24) rl1 - ISP #1 rl2 - ISP #2 tun0 - OpenVPN Tunnel to remote office (10.0.0.0/26) Right now, my pf.conf allows me to do a few things, 1. nat lan traffic out ISP #1 (this is my default ISP, however I'd like the non servers go out ISP #2) 2. binat server traffic out ISP #1 (this is good as we want our servers only to respond out specific IP's on ISP #1) 3. we have rl2 responding to pings, however can't seem to get nat traffic over to rl2 without causing problems with our tunnel to our remote office 4. we have our traffic destined for our remote office working with static routes initialized when the vpn creates the tunnel. What I'm trying to get working is to have our lan traffic go over the nat on rl2 (ISP #2) rather then rl1 (ISP#1) at the same time having our binat traffic still go over ISP #1 and our vpn traffic go over the tun0 interface. This is quickly becoming no small feat. Here is my current pf.conf file as it stands: int_if="rl0" int_net="10.1.0.0/24" ext_if1="rl1" ext_gw1="" ext_if2="rl2" ext_gw2="" server1_int="10.1.0.20" server1_out="ISP #1 External IP #2" server2_int="10.1.0.21" server2_out="ISP #1 External IP #3" server3_int="10.1.0.22" server3_out="ISP #1 External IP #4" server4_int="10.1.0.23" server4_out="ISP #1 External IP #5" nat on $ext_if1 from $int_net to any -> ($ext_if1:0) nat on $ext_if2 from $int_net to any -> ($ext_if2:0) binat on $ext_if1 from $server1_int to any -> $server1_out binat on $ext_if1 from $server2_int to any -> $server2_out binat on $ext_if1 from $server3_int to any -> $server3_out binat on $ext_if1 from $server4_int to any -> $server4_out pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any Any input would be much apreciated as always. >From: Daniel Hartmeier >To: Stephane Raimbault >CC: dionch@freemail.gr, freebsd-pf@freebsd.org >Subject: Re: route-to rule. >Date: Wed, 26 Jan 2005 00:45:13 +0100 > >On Tue, Jan 25, 2005 at 04:22:45PM -0700, Stephane Raimbault wrote: > > > Looking into audities... it seems that the nat that goes across this >line > > right now: > > > > nat on $ext_if1 from $internal_net to any -> ($ext_if1) > > > > seems to round robin the external IP as I have several IP's aliased on > > $ext_if1 if I replace the above line with this: > > > > nat on $ext_if1 from $internal_net to any -> ($ext_ip1) > > > > where $ext_ip1 is the external IP I want the nat to go out, however when >I > > do this... the lan can no longer establish new connections... any >thoughts > > on this? > >You can put () around an interface name, meaning 'dynamic interface name >to address translation'. In the first example, as you noted, this means >pf will round-robin through all addresses of the interface to pick a >source address for NATed connections. > >The second example makes no sense. If what you want is to use a constant >source address for NAT, just use > > -> $ext_ip1 > >without the parentheses. If you expect $ext_if1 to change its address >dynamically, and you want to use its 'main' address as replacement (but >not round-robin through aliases, if it has any), use > > -> ($ext_if1:0) > >If you want still something else, please explain. > >What you actually have in your second example is (surprisingly) not a >syntax error, but > > -> (10.1.2.3) > >Which means the interface with name "10.1.2.3". There is no such >interface, of course, but since pf accepts non-existant interfaces >(which could exist later on, think USB or PCMCIA nics), it accepts this. >It's still non-sensical, don't use () around IP addresses. :) > >Daniel _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Thu Jan 27 11:56:31 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1732416A4CF for ; Thu, 27 Jan 2005 11:56:31 +0000 (GMT) Received: from be1.mail.zoznam.sk (mail.zoznam.sk [62.65.179.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id C858E43D6A for ; Thu, 27 Jan 2005 11:56:27 +0000 (GMT) (envelope-from goosefreebsd@zoznam.sk) X-Spam-Status: No, hits=-2.8 required=4.0 Received: from [192.168.1.16] (HELO web7.zoznam.sk) by be1.mail.zoznam.sk (CommuniGate Pro SMTP 4.2.8) with ESMTP id 24883745 for freebsd-pf@freebsd.org; Thu, 27 Jan 2005 12:56:20 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by web7.zoznam.sk (8.13.1/8.13.1) with ESMTP id j0RArVRt096747 for ; Thu, 27 Jan 2005 11:53:31 +0100 (CET) (envelope-from goosefreebsd@zoznam.sk) Message-Id: <200501271053.j0RArVRt096747@web7.zoznam.sk> Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Date: Thu, 27 Jan 2005 10:53:31 UT From: "goose bla" To: freebsd-pf@freebsd.org X-Mailer: Zoznam Mailer v.1.2 X-Www-Freemail-Ip: 156.153.255.236 Subject: Packet filter out of control upload traffic example rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 11:56:31 -0000 Hi, pls.. can you check my PF rules for shapping. my idea was shape P2P and no important traffic and make higher priority to important traffic. download is working perfect.. if there is very big P2P download traffic and somebody want to go to www,, www page is download very fast.=20 but upload is set to 180Kbit/s and it's working on full link. i don't know why..=20 i have been using IPFW by now, but there was the same problem. traffic from inet to network worked fine,, but traffic from us to inet was out of contro= l. i read about traffic can by shape only in one way per interface.. so i must shape download traffic on one (external) and upload traffic on another (internal) interface. but i don't understand why.=20 well i have set pass rules for packet to size rules.. and size rules define what will be with packet (drop,pass).=20 so why i can't define download and upload traffic on the same interface?=20= =20 next problem is ,if i shutdown IPNAT , rdr and NAT rules are not working. i think i have rules without format mistake. thank you for your help. ext=3D"xl0" int=3D"fxp0" ext_IP=3D"{111.111.111.111}" ext_net=3D"{111.111.111.111/29}" intIP1=3D"{10.1.0.1}" intIP2=3D"{10.2.0.1}" intIP192=3D"{192.168.1.1}" intIP101=3D"{10.1.1.1}" int_net1=3D"{10.1.0.0/24}" int_net2=3D"{10.2.0.0/24}" int_net101=3D"{10.1.1.0/24}" int_net192=3D"{192.168.1.0/24}" ip1=3D"{192.168.1.3}" ip2=3D"{192.168.1.2}" #queueing altq on $int hfsc bandwidth 4Mb queue {skuska, zbyt} queue skuska {dnu, von } queue dnu hfsc { vnut_net_in, von_in } queue vnut_net_in bandwidth 1Mb hfsc (ecn, upperlimit 1Mb) queue von_in bandwidth 512Kb hfsc (ecn, upperlimit 480Kb) {spec_ip_in, ijur_in } queue spec_ip_in bandwidth 480Kb hfsc(linkshare (80% 60000 50%)) queue ijur_in hfsc { top_in, special_port_in, normal_port_in, block_port_in, stupid_pc_in } queue top_in hfsc (linkshare (10% 5000 32Kb)) queue special_port_in hfsc (linkshare (10% 5000 32Kb)) queue normal_port_in hfsc (linkshare (50% 3000 16Kb)) queue block_port_in hfsc (linkshare (1% 1000 1Kb)) queue stupid_pc_in hfsc (linkshare (1% 1000 1Kb)) queue von hfsc {vnut_net_out, von_out } queue vnut_net_out bandwidth 1Mb hfsc (ecn, upperlimit 1Mb) queue von_out bandwidth 512Kb hfsc (ecn, upperlimit 180Kb) {spec_ip_out, ijur_out} queue spec_ip_out hfsc (linkshare (80% 60000 50%)) queue ijur_out hfsc { top_out, spec_port_out, normal_port_out, block_port_out, stupid_pc_out } queue top_out hfsc (linkshare (10% 5000 32Kb)) queue spec_port_out hfsc (linkshare (10% 5000 32Kb)) queue normal_port_out hfsc (linkshare (50% 3000 16Kb)) queue block_port_out hfsc (linkshare (1% 1000 1Kb)) queue stupid_pc_out hfsc (linkshare (1% 1000 1Kb)) queue zbyt bandwidth 1Kb hfsc(default) #NAT von nat on $ext from 10.1.0.0/24 to any -> $ext_IP nat on $ext from 10.2.0.0 to any -> $ext_IP nat on $ext from 192.168.1.0 to any -> $ext_IP nat on $ext from 10.1.1.0 to any -> $ext_IP #FORWARD portov #pc1 rdr on $ext proto tcp from any to $ext port 3333 -> $ip1 port 3333 rdr on $ext proto tcp from any to $ext port 2222 -> $ip1 port 2222 rdr on $ext proto tcp from any to $ext port 2233 -> $ip1 port 2233 rdr on $ext proto {tcp udp} from any to $ext port 3322 -> $ip1 port 3322 #pc2 rdr on $ext proto tcp from any to $ext port 4421 -> $ip2 port 4421 rdr on $ext proto tcp from any to $ext port 4433 -> $ip2 port 4433 rdr on $ext proto tcp from any to $ext port 4455 -> $ip2 port 4455 rdr on $ext proto {tcp udp} from any to $ext port 5555 -> $ip2 port 5555 pass out quick on $int from any to 10.1.1.10 keep state queue special_ip_in pass in quick on $int from 10.1.1.10 to any keep state queue special_ip_out pass out quick on $int from 10.1.1.0/24 to 10.1.0.0/24 keep state queue vnut_net_in pass in quick on $int from 10.1.0.0/24 to 10.1.1.0/24 keep state queue vnut_net_out pass out quick on $int from 10.1.1.0/24 to 10.2.0.0/24 keep state queue vnut_net_in pass in quick on $int from 10.2.0.0/24 to 10.1.1.0/24 keep state queue vnut_net_out pass out quick on $int proto {tcp udp} from any port {22 23} to any keep state queue top_in pass in quick on $int proto {tcp udp} from any to any port {22 23} keep state queue top_out pass out quick on $int proto {tcp udp} from any to any port {2493 2498 2021 2023 2080 3021 3023 3080 } keep state queue spec_ip_in pass in quick on $int proto {tcp udp} from any port {2493 2498 2021 2023 2080 3021 3023 3080 } to any keep state queue spec_ip_out pass out quick on $int proto {tcp udp} from any port {80 5190 21 25 110 443 465 993 995 9000 27030} to any keep state queue normal_port_in pass in quick on $int proto {tcp udp} from any to any port {80 5190 21 25 110 443 465 993 995 9000 27030} keep state queue normal_port_out pass out quick on $int proto {tcp udp} from any to any keep state queue block_port_in pass in quick on $int proto {tcp udp} from any to any keep state queue block_port_out pass out quick on $int proto {tcp udp} from any to 10.1.1.40 keep state queue stupid_pc_in pass in quick on $int proto {tcp udp} from 10.1.1.40 to any keep state queue stupid_pc_out --- reklama ----------------------------------------------------- Pracovn=C3=A9 ponuky aj zo zahrani=C4=8Dia n=C3=A1jdete na Kari=C3=A9re. http://kariera.zoznam.sk From owner-freebsd-pf@FreeBSD.ORG Thu Jan 27 18:27:06 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E084B16A4CE for ; Thu, 27 Jan 2005 18:27:05 +0000 (GMT) Received: from hotmail.com (bay24-f23.bay24.hotmail.com [64.4.18.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8727C43D1D for ; Thu, 27 Jan 2005 18:27:05 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Jan 2005 10:26:01 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Thu, 27 Jan 2005 18:25:32 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <000d01c50411$3904d3e0$3c00000a@R3B> From: "Stephane Raimbault" To: dionch@freemail.gr, freebsd-pf@freebsd.org Date: Thu, 27 Jan 2005 11:25:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jan 2005 18:26:01.0778 (UTC) FILETIME=[A793B920:01C5049D] Subject: Re: route-to rule. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 18:27:06 -0000 Okay, with the syntax cleaned up this is what I have: set state-policy if-bound int_if="rl0" int_net="10.1.0.0/24" ext_if1="rl1" ext_gw1="" ext_if2="rl2" ext_gw2="" vpn_if="tun0" vpn_gw="172.16.0.1" isp1 = "(" $ext_if1 $ext_gw1 ")" isp2 = "(" $ext_if2 $ext_gw2 ")" vpn = "(" $vpn_if $vpn_gw ")" server1_int="10.1.0.20" server1_out="63.252.160.219" server2_int="10.1.0.21" server2_out="63.252.160.222" server3_int="10.1.0.22" server3_out="63.252.160.221" server4_int="10.1.0.23" server4_out="63.252.160.220" nat on $ext_if1 from $int_net to any -> ($ext_if1:0) nat on $ext_if2 from $int_net to any -> ($ext_if2:0) binat on $ext_if1 from $server1_int to any -> $server1_out binat on $ext_if1 from $server2_int to any -> $server2_out binat on $ext_if1 from $server3_int to any -> $server3_out binat on $ext_if1 from $server4_int to any -> $server4_out pass in quick on $int_if inet from $int_net to $int_net keep state pass out quick on $int_if inet from $int_net to $int_net keep state pass in on $ext_if1 tag $ext_if1 keep state pass out on $ext_if1 route-to $ext_if1 keep state pass out quick on $int_if reply-to $ext_if1 tagged $ext_if1 keep state pass in on $ext_if2 tag $ext_if2 keep state pass out on $ext_if2 route-to $ext_if2 keep state pass out quick on $int_if reply-to $ext_if2 tagged $ext_if2 keep state pass in on $vpn_if tag $vpn_if keep state pass out on $vpn_if route-to $vpn_if keep state pass out quick on $vpn_if reply-to $vpn_if tagged $vpn_if keep state pass in quick on $int_if route-to $isp1 from {$server1_int,$server2_int,$server3_int,$server4_int} to {!10.0.0.0/26, !$int_net} keep state pass in quick on $int_if route-to $vpn from $int_net to 10.0.0.0/26 keep state pass in on $int_if route-to $isp2 from $int_net to {!10.0.0.0/26, !$int_net} keep state I tried this out and it was not a success. It seemend like nothing could get anywhere. $int_net wasn't able to access the internet nor the subnets on the otherside of the vpn. The binat'd servers were unaccessible from the internet... and I got an arp error in the /var/log/messages about a bunch of arp's not being on the local network... I got a stream of these types of messages: Jan 27 12:12:02 router1 kernel: arplookup 69.57.244.70 failed: host is not on local network Jan 27 12:12:02 router1 kernel: arpresolve: can't allocate llinfo for 69.57.244.70 Jan 27 12:12:02 router1 kernel: arplookup 12.24.195.78 failed: host is not on local network Jan 27 12:12:02 router1 kernel: arpresolve: can't allocate llinfo for 12.24.195.78 so, we aren't quite there yet. Could I more simply change my default route to ISP #2, and setup some sort of route-to statements specifically for the binat's instead? Then I would also need to setup a rule for the openvpn to go over ISP #1 instead of ISP #2. any suggestions... as always much apreciated. Thanks, Stephane. >From: "Chris Dionissopoulos" >Reply-To: "Chris Dionissopoulos" >To: "Stephane Raimbault" >Subject: Re: route-to rule. >Date: Thu, 27 Jan 2005 03:40:43 +0200 > >Try to negate(="!") each network for "to" field like: >{ !10.0.0.0/26, !$int_net} >Also when you change line in a rule , you must backslash at the end ("\"). > >Chris. > > > >>Hi Chris, Thanks for the quick response, however I'm still getting syntax >>errors on 2 of the 3 lines now: >> >>pass in quick on $int_if route-to $isp1 from >>{$server1_int,$server2_int,$server3_int,$server4_int} to !{10.0.0.0/26, >>$int_net} keep state >>pass in quick on $int_if route-to $vpn from $int_net to 10.0.0.0/26 keep >>state >>pass in on $int_if route-to $isp2 from $int_net to !{10.0.0.0/26, >>$int_net} keep state >> >>/etc/pf.conf:47: syntax error >>/etc/pf.conf:49: syntax error >> >>Where line 47 is the first one above and 49 is the last (3rd line) above. >> >>Any thoughts? I'm scratching my head bald. >> >>Thanks, >>Stephane. >> >> > > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Sat Jan 29 07:55:38 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5C0816A4CE for ; Sat, 29 Jan 2005 07:55:38 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0603B43D53 for ; Sat, 29 Jan 2005 07:55:37 +0000 (GMT) (envelope-from sam.wun@authtec.com) Received: (qmail 76237 invoked from network); 29 Jan 2005 07:55:34 -0000 Received: from unknown (HELO [192.168.4.70]) (samwun@hgcbroadband.com@[221.127.177.32]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 29 Jan 2005 07:55:34 -0000 Message-ID: <41FB411B.1020904@authtec.com> Date: Sat, 29 Jan 2005 15:54:03 +0800 From: sam wun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org, max@love2party.net Content-Type: multipart/mixed; boundary="------------080800030902000705000701" Subject: rej files X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 07:55:39 -0000 This is a multi-part message in MIME format. --------------080800030902000705000701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I download carp patches from http://people.freebsd.org/~mlaier/CARP/20050110-carp.diff , and applied this patch to 5.3 stable (which I download and extracted with command "cvs co -r RELENG_5 src"). It generates a few rej files. Please see attached file for detail. Thanks Sam --------------080800030902000705000701 Content-Type: application/octet-stream; name="typescript" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="typescript" U2NyaXB0IHN0YXJ0ZWQgb24gU2F0IEphbiAyOSAxNTo1MDo0NSAyMDA1Ci4vCQkJUkVBRE1F CQkJZ2FtZXMvCQkJbGliZXhlYy8JCXRvb2xzLwouLi8JCQlVUERBVElORwkJZ251LwkJCXJl bGVhc2UvCQl0eXBlc2NyaXB0CkNPUFlSSUdIVAkJVVBEQVRJTkcuNjRCVFQJCWluY2x1ZGUv CQlyZXNjdWUvCQkJdXNyLmJpbi8KQ1ZTLwkJCWJpbi8JCQlpbnN0YWxsd29ybGRfbmV3ayoJ c2Jpbi8JCQl1c3Iuc2Jpbi8KTUFJTlRBSU5FUlMJCWNvbnRyaWIvCQlpbnN0YWxsd29ybGRf b2xkayoJc2VjdXJlLwpNYWtlZmlsZQkJY3J5cHRvLwkJCWtlcmJlcm9zNS8JCXNoYXJlLwpN YWtlZmlsZS5pbmMxCQlldGMvCQkJbGliLwkJCXN5cy8Kcm9vdEBnYXRld2F5IBtbMW1bMzo1 MHBtXRtbbQ8gWy91c3Ivc3JjXSMgcGF0Y2ggLXAwIDwgL3Vzci9sb2NhbC9wYXRjaGVzLzIw MDUwMTEwLWNhcnAuZGlmZg0KSG1tLi4uICBMb29rcyBsaWtlIGEgdW5pZmllZCBkaWZmIHRv IG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9ldGMvcHJvdG9jb2xzIC4vZXRjL3By b3RvY29scwp8LS0tIC4uL2Rpc3QvZXRjL3Byb3RvY29scwlTYXQgTm92ICA2IDIwOjQzOjUz IDIwMDQKfCsrKyAuL2V0Yy9wcm90b2NvbHMJRnJpIERlYyAgMyAyMTo1ODoxNyAyMDA0Ci0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9ldGMvcHJvdG9jb2xz IHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCAxMTkuCkh1bmsgIzIgc3Vj Y2VlZGVkIGF0IDE0Mi4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5p ZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zYmluL2lmY29u ZmlnL01ha2VmaWxlIC4vc2Jpbi9pZmNvbmZpZy9NYWtlZmlsZQp8LS0tIC4uL2Rpc3Qvc2Jp bi9pZmNvbmZpZy9NYWtlZmlsZQlUaHUgRGVjICA5IDAxOjUwOjExIDIwMDQKfCsrKyAuL3Ni aW4vaWZjb25maWcvTWFrZWZpbGUJVGh1IERlYyAgOSAwMjozNTo0MCAyMDA0Ci0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zYmluL2lmY29uZmlnL01ha2Vm aWxlIHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIGZhaWxlZCBhdCAyMy4KMSBvdXQgb2YgMSBo dW5rcyBmYWlsZWQtLXNhdmluZyByZWplY3RzIHRvIC4vc2Jpbi9pZmNvbmZpZy9NYWtlZmls ZS5yZWoKSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5pZmllZCBkaWZm IHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zYmluL2lmY29uZmlnL2lmY2Fy cC5jIC4vc2Jpbi9pZmNvbmZpZy9pZmNhcnAuYwp8LS0tIC4uL2Rpc3Qvc2Jpbi9pZmNvbmZp Zy9pZmNhcnAuYwlUaHUgSmFuICAxIDAxOjAwOjAwIDE5NzAKfCsrKyAuL3NiaW4vaWZjb25m aWcvaWZjYXJwLmMJRnJpIERlYyAxMCAwMTowMDowNyAyMDA0Ci0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCihDcmVhdGluZyBmaWxlIC4vc2Jpbi9pZmNvbmZpZy9pZmNhcnAuYy4uLikK UGF0Y2hpbmcgZmlsZSAuL3NiaW4vaWZjb25maWcvaWZjYXJwLmMgdXNpbmcgUGxhbiBBLi4u Ckh1bmsgIzEgc3VjY2VlZGVkIGF0IDEuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2ggbG9va3Mg bGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVwIHRvIHRo aXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4uL2Rpc3Qv c2Jpbi9pZmNvbmZpZy9pZnBmc3luYy5jIC4vc2Jpbi9pZmNvbmZpZy9pZnBmc3luYy5jCnwt LS0gLi4vZGlzdC9zYmluL2lmY29uZmlnL2lmcGZzeW5jLmMJVGh1IEphbiAgMSAwMTowMDow MCAxOTcwCnwrKysgLi9zYmluL2lmY29uZmlnL2lmcGZzeW5jLmMJRnJpIERlYyAxMCAwMTow MDowNyAyMDA0Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCihDcmVhdGluZyBmaWxlIC4v c2Jpbi9pZmNvbmZpZy9pZnBmc3luYy5jLi4uKQpQYXRjaGluZyBmaWxlIC4vc2Jpbi9pZmNv bmZpZy9pZnBmc3luYy5jIHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCAx LgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxvb2tzIGxpa2UgYSB1bmlmaWVkIGRpZmYgdG8g bWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0byB0aGlzIHdhczoKLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9kaXN0L3N5cy9jb25mL2ZpbGVzIC4vc3lzL2Nv bmYvZmlsZXMKfC0tLSAuLi9kaXN0L3N5cy9jb25mL2ZpbGVzCU1vbiBKYW4gMTAgMTM6NTU6 NDUgMjAwNQp8KysrIC4vc3lzL2NvbmYvZmlsZXMJTW9uIEphbiAxMCAxNjoxNDowMSAyMDA1 Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvY29uZi9m aWxlcyB1c2luZyBQbGFuIEEuLi4KSHVuayAjMSBmYWlsZWQgYXQgMjc5LgpIdW5rICMyIGZh aWxlZCBhdCAxNDY5LgoyIG91dCBvZiAyIGh1bmtzIGZhaWxlZC0tc2F2aW5nIHJlamVjdHMg dG8gLi9zeXMvY29uZi9maWxlcy5yZWoKSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBs aWtlIGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhp cyB3YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9z eXMvY29uZi9vcHRpb25zIC4vc3lzL2NvbmYvb3B0aW9ucwp8LS0tIC4uL2Rpc3Qvc3lzL2Nv bmYvb3B0aW9ucwlUaHUgRGVjICA5IDAxOjUwOjEzIDIwMDQKfCsrKyAuL3N5cy9jb25mL29w dGlvbnMJVGh1IERlYyAgOSAwMjowOTo1MyAyMDA0Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvY29uZi9vcHRpb25zIHVzaW5nIFBsYW4gQS4uLgpI dW5rICMxIHN1Y2NlZWRlZCBhdCA2MDggKG9mZnNldCAzIGxpbmVzKS4KSG1tLi4uICBUaGUg bmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0 IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxk aWZmIC1ydVAgLi4vZGlzdC9zeXMvaTM4Ni9jb25mL0NBUlAgLi9zeXMvaTM4Ni9jb25mL0NB UlAKfC0tLSAuLi9kaXN0L3N5cy9pMzg2L2NvbmYvQ0FSUAlUaHUgSmFuICAxIDAxOjAwOjAw IDE5NzAKfCsrKyAuL3N5cy9pMzg2L2NvbmYvQ0FSUAlTYXQgTm92ICA2IDIwOjAwOjA5IDIw MDQKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKENyZWF0aW5nIGZpbGUgLi9zeXMvaTM4 Ni9jb25mL0NBUlAuLi4pClBhdGNoaW5nIGZpbGUgLi9zeXMvaTM4Ni9jb25mL0NBUlAgdXNp bmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVkIGF0IDEuCkhtbS4uLiAgVGhlIG5leHQg cGF0Y2ggbG9va3MgbGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFk aW5nIHVwIHRvIHRoaXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAt cnVQIC4uL2Rpc3Qvc3lzL25ldC9pZi5jIC4vc3lzL25ldC9pZi5jCnwtLS0gLi4vZGlzdC9z eXMvbmV0L2lmLmMJTW9uIEphbiAxMCAxMzo1NzowOSAyMDA1CnwrKysgLi9zeXMvbmV0L2lm LmMJTW9uIEphbiAxMCAxNjoxNTozMSAyMDA1Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t ClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0L2lmLmMgdXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEg c3VjY2VlZGVkIGF0IDM0LgpIdW5rICMyIHN1Y2NlZWRlZCBhdCA3OSB3aXRoIGZ1enogMi4K SHVuayAjMyBzdWNjZWVkZWQgYXQgNTI5IChvZmZzZXQgLTQgbGluZXMpLgpIdW5rICM0IHN1 Y2NlZWRlZCBhdCA5MzkgKG9mZnNldCAtNCBsaW5lcykuCkh1bmsgIzUgc3VjY2VlZGVkIGF0 IDk2MSAob2Zmc2V0IC00IGxpbmVzKS4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBs aWtlIGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhp cyB3YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9z eXMvbmV0L2lmX2V0aGVyc3Vici5jIC4vc3lzL25ldC9pZl9ldGhlcnN1YnIuYwp8LS0tIC4u L2Rpc3Qvc3lzL25ldC9pZl9ldGhlcnN1YnIuYwlNb24gSmFuIDEwIDEzOjU3OjEwIDIwMDUK fCsrKyAuL3N5cy9uZXQvaWZfZXRoZXJzdWJyLmMJTW9uIEphbiAxMCAxNjoxNTozMiAyMDA1 Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0L2lm X2V0aGVyc3Vici5jIHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCAzNy4K SHVuayAjMiBzdWNjZWVkZWQgYXQgNzQuCkh1bmsgIzMgc3VjY2VlZGVkIGF0IDMyMC4KSHVu ayAjNCBzdWNjZWVkZWQgYXQgNjU5IChvZmZzZXQgNDQgbGluZXMpLgpIdW5rICM1IHN1Y2Nl ZWRlZCBhdCA2OTQgKG9mZnNldCA0NCBsaW5lcykuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2gg bG9va3MgbGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVw IHRvIHRoaXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4u L2Rpc3Qvc3lzL25ldC9pZl9tZWRpYS5oIC4vc3lzL25ldC9pZl9tZWRpYS5oCnwtLS0gLi4v ZGlzdC9zeXMvbmV0L2lmX21lZGlhLmgJTW9uIEphbiAxMCAxMzo1NzoxMCAyMDA1CnwrKysg Li9zeXMvbmV0L2lmX21lZGlhLmgJTW9uIEphbiAxMCAxNjoxNTozMyAyMDA1Ci0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0L2lmX21lZGlhLmgg dXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVkIGF0IDIyNy4KSHVuayAjMiBzdWNj ZWVkZWQgYXQgMzA0LgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxvb2tzIGxpa2UgYSB1bmlm aWVkIGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0byB0aGlzIHdhczoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9kaXN0L3N5cy9uZXQvaWZf dHlwZXMuaCAuL3N5cy9uZXQvaWZfdHlwZXMuaAp8LS0tIC4uL2Rpc3Qvc3lzL25ldC9pZl90 eXBlcy5oCU1vbiBKYW4gMTAgMTM6NTc6MTEgMjAwNQp8KysrIC4vc3lzL25ldC9pZl90eXBl cy5oCU1vbiBKYW4gMTAgMTY6MTU6MzQgMjAwNQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQpQYXRjaGluZyBmaWxlIC4vc3lzL25ldC9pZl90eXBlcy5oIHVzaW5nIFBsYW4gQS4uLgpI dW5rICMxIHN1Y2NlZWRlZCBhdCAyNDcuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2ggbG9va3Mg bGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVwIHRvIHRo aXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4uL2Rpc3Qv c3lzL25ldC9pZl92YXIuaCAuL3N5cy9uZXQvaWZfdmFyLmgKfC0tLSAuLi9kaXN0L3N5cy9u ZXQvaWZfdmFyLmgJTW9uIEphbiAxMCAxMzo1NzoxMSAyMDA1CnwrKysgLi9zeXMvbmV0L2lm X3Zhci5oCU1vbiBKYW4gMTAgMTY6MTU6MzQgMjAwNQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpQYXRjaGluZyBmaWxlIC4vc3lzL25ldC9pZl92YXIuaCB1c2luZyBQbGFuIEEuLi4K SHVuayAjMSBzdWNjZWVkZWQgYXQgNjguCkh1bmsgIzIgc3VjY2VlZGVkIGF0IDE0OSAob2Zm c2V0IDIgbGluZXMpLgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxvb2tzIGxpa2UgYSB1bmlm aWVkIGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0byB0aGlzIHdhczoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9kaXN0L3N5cy9uZXRpbmV0 L2lmX2V0aGVyLmMgLi9zeXMvbmV0aW5ldC9pZl9ldGhlci5jCnwtLS0gLi4vZGlzdC9zeXMv bmV0aW5ldC9pZl9ldGhlci5jCU1vbiBKYW4gMTAgMTM6NTc6MjMgMjAwNQp8KysrIC4vc3lz L25ldGluZXQvaWZfZXRoZXIuYwlNb24gSmFuIDEwIDE2OjE1OjUwIDIwMDUKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KUGF0Y2hpbmcgZmlsZSAuL3N5cy9uZXRpbmV0L2lmX2V0aGVy LmMgdXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVkIGF0IDM5LgpIdW5rICMyIHN1 Y2NlZWRlZCBhdCA2OC4KSHVuayAjMyBzdWNjZWVkZWQgYXQgNTUwLgpIdW5rICM0IHN1Y2Nl ZWRlZCBhdCA1NjkuCkh1bmsgIzUgc3VjY2VlZGVkIGF0IDYwMS4KSHVuayAjNiBzdWNjZWVk ZWQgYXQgNzI3LgpIdW5rICM3IHN1Y2NlZWRlZCBhdCA3NTQuCkh1bmsgIzggc3VjY2VlZGVk IGF0IDg5Mi4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5pZmllZCBk aWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zeXMvbmV0aW5ldC9pZl9l dGhlci5oIC4vc3lzL25ldGluZXQvaWZfZXRoZXIuaAp8LS0tIC4uL2Rpc3Qvc3lzL25ldGlu ZXQvaWZfZXRoZXIuaAlNb24gSmFuIDEwIDEzOjU3OjIzIDIwMDUKfCsrKyAuL3N5cy9uZXRp bmV0L2lmX2V0aGVyLmgJTW9uIEphbiAxMCAxNjoxNTo1MCAyMDA1Ci0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0aW5ldC9pZl9ldGhlci5oIHVz aW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCAxMTIuCkhtbS4uLiAgVGhlIG5l eHQgcGF0Y2ggbG9va3MgbGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBs ZWFkaW5nIHVwIHRvIHRoaXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlm ZiAtcnVQIC4uL2Rpc3Qvc3lzL25ldGluZXQvaW4uaCAuL3N5cy9uZXRpbmV0L2luLmgKfC0t LSAuLi9kaXN0L3N5cy9uZXRpbmV0L2luLmgJTW9uIEphbiAxMCAxMzo1NzoyMyAyMDA1Cnwr KysgLi9zeXMvbmV0aW5ldC9pbi5oCU1vbiBKYW4gMTAgMTY6MTU6NTAgMjAwNQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpQYXRjaGluZyBmaWxlIC4vc3lzL25ldGluZXQvaW4uaCB1 c2luZyBQbGFuIEEuLi4KSHVuayAjMSBzdWNjZWVkZWQgYXQgMjMwLgpIdW5rICMyIHN1Y2Nl ZWRlZCBhdCAzNTIgKG9mZnNldCAtNiBsaW5lcykuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2gg bG9va3MgbGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVw IHRvIHRoaXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4u L2Rpc3Qvc3lzL25ldGluZXQvaW5fcHJvdG8uYyAuL3N5cy9uZXRpbmV0L2luX3Byb3RvLmMK fC0tLSAuLi9kaXN0L3N5cy9uZXRpbmV0L2luX3Byb3RvLmMJTW9uIEphbiAxMCAxMzo1Nzoy MyAyMDA1CnwrKysgLi9zeXMvbmV0aW5ldC9pbl9wcm90by5jCU1vbiBKYW4gMTAgMTY6MTU6 NTAgMjAwNQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQYXRjaGluZyBmaWxlIC4vc3lz L25ldGluZXQvaW5fcHJvdG8uYyB1c2luZyBQbGFuIEEuLi4KSHVuayAjMSBzdWNjZWVkZWQg YXQgMzYgKG9mZnNldCAxIGxpbmUpLgpIdW5rICMyIHN1Y2NlZWRlZCBhdCA5MiB3aXRoIGZ1 enogMiAob2Zmc2V0IDEgbGluZSkuCkh1bmsgIzMgZmFpbGVkIGF0IDI0My4KSHVuayAjNCBz dWNjZWVkZWQgYXQgMjk3IHdpdGggZnV6eiAxIChvZmZzZXQgLTUgbGluZXMpLgoxIG91dCBv ZiA0IGh1bmtzIGZhaWxlZC0tc2F2aW5nIHJlamVjdHMgdG8gLi9zeXMvbmV0aW5ldC9pbl9w cm90by5jLnJlagpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxvb2tzIGxpa2UgYSB1bmlmaWVk IGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0byB0aGlzIHdhczoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9kaXN0L3N5cy9uZXRpbmV0L2lw X2NhcnAuYyAuL3N5cy9uZXRpbmV0L2lwX2NhcnAuYwp8LS0tIC4uL2Rpc3Qvc3lzL25ldGlu ZXQvaXBfY2FycC5jCVRodSBKYW4gIDEgMDE6MDA6MDAgMTk3MAp8KysrIC4vc3lzL25ldGlu ZXQvaXBfY2FycC5jCUZyaSBEZWMgIDMgMjE6NTg6MTggMjAwNAotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQooQ3JlYXRpbmcgZmlsZSAuL3N5cy9uZXRpbmV0L2lwX2NhcnAuYy4uLikK UGF0Y2hpbmcgZmlsZSAuL3N5cy9uZXRpbmV0L2lwX2NhcnAuYyB1c2luZyBQbGFuIEEuLi4K SHVuayAjMSBzdWNjZWVkZWQgYXQgMS4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBs aWtlIGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhp cyB3YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9z eXMvbmV0aW5ldC9pcF9jYXJwLmggLi9zeXMvbmV0aW5ldC9pcF9jYXJwLmgKfC0tLSAuLi9k aXN0L3N5cy9uZXRpbmV0L2lwX2NhcnAuaAlUaHUgSmFuICAxIDAxOjAwOjAwIDE5NzAKfCsr KyAuL3N5cy9uZXRpbmV0L2lwX2NhcnAuaAlTYXQgTm92ICA2IDE4OjEzOjQ3IDIwMDQKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKENyZWF0aW5nIGZpbGUgLi9zeXMvbmV0aW5ldC9p cF9jYXJwLmguLi4pClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0aW5ldC9pcF9jYXJwLmggdXNp bmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVkIGF0IDEuCkhtbS4uLiAgVGhlIG5leHQg cGF0Y2ggbG9va3MgbGlrZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFk aW5nIHVwIHRvIHRoaXMgd2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAt cnVQIC4uL2Rpc3Qvc3lzL25ldGluZXQvaXBfaW5wdXQuYyAuL3N5cy9uZXRpbmV0L2lwX2lu cHV0LmMKfC0tLSAuLi9kaXN0L3N5cy9uZXRpbmV0L2lwX2lucHV0LmMJTW9uIEphbiAxMCAx Mzo1NzoyNCAyMDA1CnwrKysgLi9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jCU1vbiBKYW4gMTAg MTY6MTU6NTIgMjAwNQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQYXRjaGluZyBmaWxl IC4vc3lzL25ldGluZXQvaXBfaW5wdXQuYyB1c2luZyBQbGFuIEEuLi4KSHVuayAjMSBzdWNj ZWVkZWQgYXQgMzUuCkh1bmsgIzIgc3VjY2VlZGVkIGF0IDY3LgpIdW5rICMzIHN1Y2NlZWRl ZCBhdCA1MTMuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2ggbG9va3MgbGlrZSBhIHVuaWZpZWQg ZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVwIHRvIHRoaXMgd2FzOgotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4uL2Rpc3Qvc3lzL25ldGluZXQ2L2lu Ni5jIC4vc3lzL25ldGluZXQ2L2luNi5jCnwtLS0gLi4vZGlzdC9zeXMvbmV0aW5ldDYvaW42 LmMJTW9uIEphbiAxMCAxMzo1NzoyNyAyMDA1CnwrKysgLi9zeXMvbmV0aW5ldDYvaW42LmMJ TW9uIEphbiAxMCAxNjoxNTo1NCAyMDA1Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBh dGNoaW5nIGZpbGUgLi9zeXMvbmV0aW5ldDYvaW42LmMgdXNpbmcgUGxhbiBBLi4uCkh1bmsg IzEgc3VjY2VlZGVkIGF0IDIwNi4KSHVuayAjMiBzdWNjZWVkZWQgYXQgMjI2LgpIdW5rICMz IHN1Y2NlZWRlZCBhdCAxNTQ5LgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxvb2tzIGxpa2Ug YSB1bmlmaWVkIGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0byB0aGlzIHdh czoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9kaXN0L3N5cy9u ZXRpbmV0Ni9pbjZfaWZhdHRhY2guYyAuL3N5cy9uZXRpbmV0Ni9pbjZfaWZhdHRhY2guYwp8 LS0tIC4uL2Rpc3Qvc3lzL25ldGluZXQ2L2luNl9pZmF0dGFjaC5jCU1vbiBKYW4gMTAgMTM6 NTc6MjcgMjAwNQp8KysrIC4vc3lzL25ldGluZXQ2L2luNl9pZmF0dGFjaC5jCU1vbiBKYW4g MTAgMTY6MTU6NTUgMjAwNQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQYXRjaGluZyBm aWxlIC4vc3lzL25ldGluZXQ2L2luNl9pZmF0dGFjaC5jIHVzaW5nIFBsYW4gQS4uLgpIdW5r ICMxIHN1Y2NlZWRlZCBhdCA2NzEuCkhtbS4uLiAgVGhlIG5leHQgcGF0Y2ggbG9va3MgbGlr ZSBhIHVuaWZpZWQgZGlmZiB0byBtZS4uLgpUaGUgdGV4dCBsZWFkaW5nIHVwIHRvIHRoaXMg d2FzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8ZGlmZiAtcnVQIC4uL2Rpc3Qvc3lz L25ldGluZXQ2L2luNl9wcm90by5jIC4vc3lzL25ldGluZXQ2L2luNl9wcm90by5jCnwtLS0g Li4vZGlzdC9zeXMvbmV0aW5ldDYvaW42X3Byb3RvLmMJTW9uIEphbiAxMCAxMzo1NzoyNyAy MDA1CnwrKysgLi9zeXMvbmV0aW5ldDYvaW42X3Byb3RvLmMJTW9uIEphbiAxMCAxNjoxNTo1 NSAyMDA1Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMv bmV0aW5ldDYvaW42X3Byb3RvLmMgdXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVk IGF0IDY0LgpIdW5rICMyIHN1Y2NlZWRlZCBhdCAxMjIuCkh1bmsgIzMgc3VjY2VlZGVkIGF0 IDI0Ni4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5pZmllZCBkaWZm IHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zeXMvbmV0aW5ldDYvaW42X3Zh ci5oIC4vc3lzL25ldGluZXQ2L2luNl92YXIuaAp8LS0tIC4uL2Rpc3Qvc3lzL25ldGluZXQ2 L2luNl92YXIuaAlNb24gSmFuIDEwIDEzOjU3OjI3IDIwMDUKfCsrKyAuL3N5cy9uZXRpbmV0 Ni9pbjZfdmFyLmgJTW9uIEphbiAxMCAxNjoxNTo1NSAyMDA1Ci0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0aW5ldDYvaW42X3Zhci5oIHVzaW5n IFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCA1NzguCkh1bmsgIzIgc3VjY2VlZGVk IGF0IDYwNi4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEgdW5pZmllZCBk aWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6Ci0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zeXMvbmV0aW5ldDYvbmQ2 LmMgLi9zeXMvbmV0aW5ldDYvbmQ2LmMKfC0tLSAuLi9kaXN0L3N5cy9uZXRpbmV0Ni9uZDYu YwlNb24gSmFuIDEwIDEzOjU3OjI5IDIwMDUKfCsrKyAuL3N5cy9uZXRpbmV0Ni9uZDYuYwlN b24gSmFuIDEwIDE2OjE1OjU3IDIwMDUKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUGF0 Y2hpbmcgZmlsZSAuL3N5cy9uZXRpbmV0Ni9uZDYuYyB1c2luZyBQbGFuIEEuLi4KSHVuayAj MSBzdWNjZWVkZWQgYXQgMjAyNS4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtl IGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3 YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zeXMv bmV0aW5ldDYvbmQ2X25ici5jIC4vc3lzL25ldGluZXQ2L25kNl9uYnIuYwp8LS0tIC4uL2Rp c3Qvc3lzL25ldGluZXQ2L25kNl9uYnIuYwlNb24gSmFuIDEwIDEzOjU3OjI5IDIwMDUKfCsr KyAuL3N5cy9uZXRpbmV0Ni9uZDZfbmJyLmMJTW9uIEphbiAxMCAxNjoxNTo1NyAyMDA1Ci0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi9zeXMvbmV0aW5ldDYv bmQ2X25ici5jIHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCAzMi4KSHVu ayAjMiBzdWNjZWVkZWQgYXQgNjEuCkh1bmsgIzMgc3VjY2VlZGVkIGF0IDEwMC4KSHVuayAj NCBzdWNjZWVkZWQgYXQgMTk5LgpIdW5rICM1IHN1Y2NlZWRlZCBhdCA5MDEuCkh1bmsgIzYg c3VjY2VlZGVkIGF0IDk2Mi4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29rcyBsaWtlIGEg dW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8gdGhpcyB3YXM6 Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlzdC9zeXMvc3lz L21idWYuaCAuL3N5cy9zeXMvbWJ1Zi5oCnwtLS0gLi4vZGlzdC9zeXMvc3lzL21idWYuaAlU aHUgRGVjICA5IDAxOjUwOjM5IDIwMDQKfCsrKyAuL3N5cy9zeXMvbWJ1Zi5oCVRodSBEZWMg IDkgMDI6MTA6MTcgMjAwNAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpQYXRjaGluZyBm aWxlIC4vc3lzL3N5cy9tYnVmLmggdXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVk IGF0IDY0MyAob2Zmc2V0IC0xIGxpbmVzKS4KSG1tLi4uICBUaGUgbmV4dCBwYXRjaCBsb29r cyBsaWtlIGEgdW5pZmllZCBkaWZmIHRvIG1lLi4uClRoZSB0ZXh0IGxlYWRpbmcgdXAgdG8g dGhpcyB3YXM6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnxkaWZmIC1ydVAgLi4vZGlz dC91c3IuYmluL25ldHN0YXQvaW5ldC5jIC4vdXNyLmJpbi9uZXRzdGF0L2luZXQuYwp8LS0t IC4uL2Rpc3QvdXNyLmJpbi9uZXRzdGF0L2luZXQuYwlTYXQgTm92ICA2IDIxOjAzOjQzIDIw MDQKfCsrKyAuL3Vzci5iaW4vbmV0c3RhdC9pbmV0LmMJRnJpIERlYyAgMyAyMTo1ODoxOCAy MDA0Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBhdGNoaW5nIGZpbGUgLi91c3IuYmlu L25ldHN0YXQvaW5ldC5jIHVzaW5nIFBsYW4gQS4uLgpIdW5rICMxIHN1Y2NlZWRlZCBhdCA1 MS4KSHVuayAjMiBzdWNjZWVkZWQgYXQgNTI0LgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNoIGxv b2tzIGxpa2UgYSB1bmlmaWVkIGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1cCB0 byB0aGlzIHdhczoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAuLi9k aXN0L3Vzci5iaW4vbmV0c3RhdC9tYWluLmMgLi91c3IuYmluL25ldHN0YXQvbWFpbi5jCnwt LS0gLi4vZGlzdC91c3IuYmluL25ldHN0YXQvbWFpbi5jCU1vbiBKYW4gMTAgMTM6NTc6NTcg MjAwNQp8KysrIC4vdXNyLmJpbi9uZXRzdGF0L21haW4uYwlNb24gSmFuIDEwIDE2OjE2OjI0 IDIwMDUKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUGF0Y2hpbmcgZmlsZSAuL3Vzci5i aW4vbmV0c3RhdC9tYWluLmMgdXNpbmcgUGxhbiBBLi4uCkh1bmsgIzEgc3VjY2VlZGVkIGF0 IDEzNi4KSHVuayAjMiBzdWNjZWVkZWQgYXQgMTczLgpIbW0uLi4gIFRoZSBuZXh0IHBhdGNo IGxvb2tzIGxpa2UgYSB1bmlmaWVkIGRpZmYgdG8gbWUuLi4KVGhlIHRleHQgbGVhZGluZyB1 cCB0byB0aGlzIHdhczoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KfGRpZmYgLXJ1UCAu Li9kaXN0L3Vzci5iaW4vbmV0c3RhdC9uZXRzdGF0LmggLi91c3IuYmluL25ldHN0YXQvbmV0 c3RhdC5oCnwtLS0gLi4vZGlzdC91c3IuYmluL25ldHN0YXQvbmV0c3RhdC5oCVNhdCBOb3Yg IDYgMjE6MDM6NDQgMjAwNAp8KysrIC4vdXNyLmJpbi9uZXRzdGF0L25ldHN0YXQuaAlTYXQg Tm92ICA2IDE4OjEzOjQ5IDIwMDQKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUGF0Y2hp bmcgZmlsZSAuL3Vzci5iaW4vbmV0c3RhdC9uZXRzdGF0LmggdXNpbmcgUGxhbiBBLi4uCkh1 bmsgIzEgc3VjY2VlZGVkIGF0IDcxLgpkb25lCnJvb3RAZ2F0ZXdheSAbWzFtWzM6NTBwbV0b W20PIFsvdXNyL3NyY10jIGV4aXQNCmV4aXQKClNjcmlwdCBkb25lIG9uIFNhdCBKYW4gMjkg MTU6NTE6MDEgMjAwNQo= --------------080800030902000705000701-- From owner-freebsd-pf@FreeBSD.ORG Sat Jan 29 14:14:55 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D58F716A4CE for ; Sat, 29 Jan 2005 14:14:55 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 641AD43D3F for ; Sat, 29 Jan 2005 14:14:55 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CutMx-0000Th-00; Sat, 29 Jan 2005 15:14:35 +0100 Received: from [217.83.14.22] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CutMx-0002gH-00; Sat, 29 Jan 2005 15:14:35 +0100 From: Max Laier To: sam wun Date: Sat, 29 Jan 2005 15:14:06 +0100 User-Agent: KMail/1.7.2 References: <41FB411B.1020904@authtec.com> In-Reply-To: <41FB411B.1020904@authtec.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2236495.vTyxBSarz9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501291514.25996.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-pf@freebsd.org Subject: Re: rej files X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 14:14:55 -0000 --nextPart2236495.vTyxBSarz9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 29 January 2005 08:54, sam wun wrote: > Hi, > > I download carp patches from > http://people.freebsd.org/~mlaier/CARP/20050110-carp.diff > , and > applied this patch to 5.3 stable (which I download and extracted with > command "cvs co -r RELENG_5 src"). It generates a few rej files. Please > see attached file for detail. You want: http://people.freebsd.org/~mlaier/CARP/20041212-carp.RELENG_5.diff =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2236495.vTyxBSarz9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB+5pBXyyEoT62BG0RAnT/AJ44B1Xh6XRqgi3VqDW7iDyg3DgRfwCdFEGv t66SQ/YSg0q+GJJKYpF21p4= =UG44 -----END PGP SIGNATURE----- --nextPart2236495.vTyxBSarz9--