From owner-freebsd-pf@FreeBSD.ORG Mon Oct 13 22:05:49 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F666E28 for ; Mon, 13 Oct 2014 22:05:49 +0000 (UTC) Received: from nm3-vm1.bullet.mail.bf1.yahoo.com (nm3-vm1.bullet.mail.bf1.yahoo.com [98.139.213.167]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F40BC7E6 for ; Mon, 13 Oct 2014 22:05:48 +0000 (UTC) Received: from [66.196.81.173] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 22:03:44 -0000 Received: from [98.139.212.213] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 22:03:44 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 22:03:44 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 250743.8408.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 95760 invoked by uid 60001); 13 Oct 2014 22:03:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1413237824; bh=bEZikZY2E6TGpDfJssR0fOsdffbb8AeafB+rI4oAOao=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=t+FIXBGcNvNTouq89mc17MXeXxZqgM04r0PForqWvWNHMwMIZ1AtE34MVt8qS1Y9ZY24zUvh+eUvi7Kma6wyuKn8GuCq2lvhSfbBIdwPW+IX6CXzctkhP41Y6c5rvm/fyhn/dxDGlV/+wXQf4bfj2ywOoGnloq9OBP/BR1chfyE= X-YMail-OSG: QXZ0XtMVM1n.8cCpxjBMhDkwavhzqHO_o8geAw4UazgOzEb CQNRKvBck0.IAPY_OfghBnBKjC6uAfTUV0Nocpg.RarUAjpAFdjQi5ZMw41J xoVPaofgthDdxzWwl5bO.0A5X_Vzxby6CAInhO3PYsqMZUOmsR5uLNxppD6s xJ1EwjjfD9D8VqI9MbHFPDclHGbkcD.FCEur9QV.2095UAtDk30uVrdcJLuc MLLZw_zpzpgBM1KCk7rbtFyLvFQaRkQKExapVcFXNX7jzDcjU0_nfyDvpFhy r4n_HMaT1nAQ4kMxob5k3uSWDCBZy4xaIZFjcehhS_cQ0hVmD5BeswnUAGu4 saLPMbMzydZ4s6cBXd4rLYYJ2abCbgTUNQpH7Rbx8bK98KeA41SACZopjEyY rJeIwVsWEq0fl5tThbzfCKkDmfIPJeQl8.O..8Z0wMEeGAfIfvxLhCIzAk4T aSn2qz3hPDs7Mn898nlDTqQL1vEhTca12O.gjm3o2hffbqnso4TvNqOrp08j OFGGRIKVdIZB6QAGtHFpDdWaBYdgSkzpy8we6WL5jgxhkakcBuUfLlm9aDab MhbIsLJ6vfII4ZI5VllvQcJxcBHo.CdZMKKOwUpxOJum.lu9ETIj9zLP9Jgh EE0v0TKV4Dr6w.y2BfSwCx2Oq8YT4shWjJu9eMphpCc56ktkA1K4yimPiIou jjBnK_a8UHQDjkDrA4jPS4MuSka50fMoPgW1ALaiEYwJykitJVNMBNq7hCmg NdO3p Received: from [178.48.83.58] by web160702.mail.bf1.yahoo.com via HTTP; Mon, 13 Oct 2014 15:03:44 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmsgeW91IERhbmllbCEKCgpPbiBGcmlkYXksIFNlcHRlbWJlciAyNiwgMjAxNCAxOjUxIFBNLCBEYW5pZWwgSGFydG1laWVyIDxkYW5pZWxAYmVuemVkcmluZS5jeD4gd3JvdGU6CiAKCgpPbiBUaHUsIFNlcCAyNSwgMjAxNCBhdCAxMToyNDowMUFNIC0wNzAwLCBMYXN6bG8gRGFuaWVsaXN6IHZpYSBmcmVlYnNkLXBmIHdyb3RlOgoKPiBJIHdhcyB3b25kZXJpbmcgaG93IGlzIHBvc3NpYmxlIHRvIGFjY2VwdCBhIGNvbm5lY3Rpb24sIGxldHMgc2F5IG9uIHBvcnQgODAgb25seSBpZiBpdCBjb21lcyBmcm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <1411669441.95769.YahooMailNeo@web160705.mail.bf1.yahoo.com> <20140926112213.GA18108@insomnia.benzedrine.cx> Message-ID: <1413237824.91751.YahooMailNeo@web160702.mail.bf1.yahoo.com> Date: Mon, 13 Oct 2014 15:03:44 -0700 From: Laszlo Danielisz Reply-To: Laszlo Danielisz Subject: Re: referer filtering To: Daniel Hartmeier In-Reply-To: <20140926112213.GA18108@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-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, 13 Oct 2014 22:05:49 -0000 Thank you Daniel! On Friday, September 26, 2014 1:51 PM, Daniel Hartmeier wrote: On Thu, Sep 25, 2014 at 11:24:01AM -0700, Laszlo Danielisz via freebsd-pf wrote: > I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer. > Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A. You mean filtering based on a HTTP Referer: header? pf doesn't work on that layer at all. Technically, B has to accept the client's connection and read the HTTP request (for the Referer: header) to make its decision. It can produce an error (or redirect) or close the connection, but "not accepting the connection" is impossible. You'd have to do this at the application layer, e.g. Apache has modules that allow access control based on HTTP headers[1], or use a HTTP proxy like squid (pf can assist redirecting to it). Also note that the referer header isn't always reliable, as it can be faked easily[2]. HTH, Daniel [1] http://www.uiowa.edu/server/manual/mod/mod_access_referer.html#motivation [2] http://www.stardrifter.org/refcontrol/ _______________________________________________ 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 Tue Oct 14 09:40:38 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FA8310C for ; Tue, 14 Oct 2014 09:40:38 +0000 (UTC) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.bemta14.messagelabs.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE7D182 for ; Tue, 14 Oct 2014 09:40:37 +0000 (UTC) Received: from [85.158.140.211:50505] by server-1.bemta-14.messagelabs.com id 80/AE-24760-AFDEC345; Tue, 14 Oct 2014 09:33:46 +0000 X-Env-Sender: Aleksej.Spenst@harman.com X-Msg-Ref: server-4.tower-194.messagelabs.com!1413279225!20262222!1 X-Originating-IP: [194.121.90.173] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2559 invoked from network); 14 Oct 2014 09:33:45 -0000 Received: from unassigned (HELO HIKAWSEXHC04.ad.harman.com) (194.121.90.173) by server-4.tower-194.messagelabs.com with AES128-SHA encrypted SMTP; 14 Oct 2014 09:33:45 -0000 Received: from HIKAWSEXMB02.ad.harman.com ([169.254.2.176]) by HIKAWSEXHC04.ad.harman.com ([172.16.1.114]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 11:33:45 +0200 From: "Spenst, Aleksej" To: "freebsd-pf@freebsd.org" Subject: Fragmented packets are not redirected Thread-Topic: Fragmented packets are not redirected Thread-Index: Ac/nkfAvIWGsjtOvSuyBBqYZc4mz4g== Date: Tue, 14 Oct 2014 09:33:44 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.102.147] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-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, 14 Oct 2014 09:40:38 -0000 Hi All, I have one problem with redirection of the fragmented packets. My use case: A mobile phone sends the RTP video stream to my server. The server has the = pf installed. All RTP packets are redirected from the server to my PC: |Mobile|------>---RTP---->-----|Server|------->---RTP--->-----|PC| The small RTP packets are redirected to my PC without any problems. The problem is with the large RTP packets that are fragmented and transmitt= ed in several IP fragments. These IP fragments are not redirected to PC. Th= e redirection rule at the server: rdr on wlan0 proto udp from any to (self) port 9870 -> 192.168.0.1 port 987= 0 | S e r v e r | ->--|wlan0 eth0|-->-------|PC 192.168.0.1| It is clear that if the IP fragments are not reassembled at the server they= cannot be redirected since the redirection rule is written for UDP packets= . That is why I have this scrub rule at the very beginning of my pf.conf: scrub in on wlan0 all I thought that this rule should reassemble all the incoming fragments. The = reassembled UDP packets should be then correctly passed through the rdr rul= e and redirected to my PC. But this does not happen. Do you have any ideas/tips? Thanks a lot! Aleksej.