From owner-freebsd-pf@FreeBSD.ORG Fri Nov 7 13:33:40 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 DE4D9A7 for ; Fri, 7 Nov 2014 13:33:39 +0000 (UTC) Received: from nm16-vm5.bullet.mail.gq1.yahoo.com (nm16-vm5.bullet.mail.gq1.yahoo.com [98.137.177.253]) (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 ABCCC3B4 for ; Fri, 7 Nov 2014 13:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s2048; t=1415367213; bh=yMw/skWluYORBusLEfXlgALv4Mn7K+bw1NrqqUKh6nk=; h=Date:From:To:Subject:From:Subject; b=PwGgw9G9ch1bFEu0Ju1m2oqHQuNcIqjSuGQ/NN3h7GiQ8v6Jq5FbNagdx9OxE2f8Tlo8zyGTF944d5s9lCxdzgVL3Cu0DHGtFgUhjdlOQnRTsBsHOgyXWMWoPXPXV1Yk+z6ZZb1j48DatTlzzAzFUTgE6IZUj9ehx7EY67abcU2Ouj4305c1lBfg6VfV5teBy1yJI8a4G0DwBxJQALUa55ckmq27hKvPrXwl9LC5+J9vMDP9KteQysNq9YSVfIkmuQ6vtoHWL5ZeZidk0kOldg40MqztMelPz69P3F4I6tKt9I0j7YzJXA3yWGuLnydRBEKPiukK/gb3av/hEpQ+SA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.br; b=acAXZCmgVMppyMGrMuyG9R50E21cqGYPw0q9lHNkP7+N1hGXpPAW92/8iBQPPI2FE2xvNL8C1wh7gJofLxn6clh9G19eaYM2qeU2y3WLM9hTtm1PcLnUEWwPHm5KqrIqcCbAZDJbC+X6cVqKj6VO0RbjrfmOCJzpLRmEJXzC1QcZgCX50Fk5LDiQUTwy4FqQuGnXwvfNMMFy8LKoqpZk9XaeLWVVVyyF/ZVbj/EksqLwyiapiHoHlz01JmC6t2XM8LEEeUMt1qRDALgTsdIGICZd7Q0nY0X5fhT80PKIqS+AgQl33VvIC+Ck0SHIRJvdDUbbmplgGkNNQcRWBkBetw==; Received: from [216.39.60.182] by nm16.bullet.mail.gq1.yahoo.com with NNFMP; 07 Nov 2014 13:33:33 -0000 Received: from [208.71.42.213] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 07 Nov 2014 13:33:33 -0000 Received: from [127.0.0.1] by smtp224.mail.gq1.yahoo.com with NNFMP; 07 Nov 2014 13:33:33 -0000 X-Yahoo-Newman-Id: 535662.76602.bm@smtp224.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BXrYK5AVM1kYKTK_.SsGQBgBHTbiap.6C3O2Zj_eKaCYJpl s0yJ9Xcw9e.NtN3frrFRv0k06mh4tOe3CSio1ziJeVu2TyLpgH34kolI5q0N Vm3dNIRwEiQdy6JbrzthmjjV_Wp1qXKUjoh81OwVzEqpDcvv10mIhP46RoT3 _MQbsDMfp1s5P.qZqAYr9vbO_ZknEM5LqKFYp_hzQHdTjHGmvV6ljIPBQG8i Y5rCI5CMuT9egg75iV9XtUJVJW6Urf1P.9tf05U6iNtI0vtIdspP6n13Dsys 3KcQ3Xgaq3uzXXQfoy8zqSYxGvymvFV2.xQ0eX2ew.P4W4FQq747qPpgYYza byrlncrPoBEsGe.IaADFZarH4kMxSZjjkZ2g8imAu5mjdvo_yFTz57pObIUM Q97ZGUs26wKDxSo77nLkt_aZtyYjnHe_6d3sGJaiJ.F75X81Ag5TA5MYW8t0 VfAZc0zCv_BZk8nR.NQUP5ViqIqGPRbL_TFXgwiRAjEYlEg4Bk17j0MGQ7tc apQmNSJPB86VJOT2rO55SilrLH8Rldw-- X-Yahoo-SMTP: yVKjEg6swBAbqx17qXEUBq0TLXllzyKK Message-ID: <545CCA52.8090605@yahoo.com.br> Date: Fri, 07 Nov 2014 10:34:10 -0300 From: spiderslack User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: doubt route-to pf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 07 Nov 2014 13:33:40 -0000 Hello people. I registered on the list and hope to learn and help. I'm in an environment with pf only with valid addresses and carp and vlan.(not nat) Today I have a freebsd with three interfaces RE0 - WAN re1 - LAN alc0 - proxy (mara cache) The proxy is in transparent mode or whether the client accesses the site and leaves bound with its own IP address, not the IP address of the proxy. I'm doing an analysis the following doubts about the parameter "route-to" if it would work for a destination that is directly connected. Well let my analysis via tcpdump. Imagine a customer makes a request on port 80 destined to google for example. The proxy is in transparent mode, ie, as the squid TPROXY module works When the request going through my freebsd bound to google and destination port 80 it uses the "route-to" and redirects it to the proxy because the destination of the packet is NOT directly connected. The proxy does spoofing the ip address of google and closes the three way handshake with the client. Thereafter if the proxy does not have the cached object creates a new connection to google to find this object. The proxy sends a SYN to google with source ip address of the client and not on its own IP (navigation for this internal network not be done by just one single IP address, each cached content and to its IP address. this avoids the controls that exist on site like 4shared, etc) The google responds with a packet with the flags "SYN/ACK" to the ip address of the client (spoof) by proxy. When this packet with the flags "SYN/ACK" arrives in FreeBSD it possesses a rule to return to return to the proxy with the parameter "route-to". as an example below. pass in log quick on RE0 route-to ($ alc0 proxy) proto tcp from any port 80 to $ rede_lan My theory is that FreeBSD and pf, are directly connected to the client, then do not use the "route-to" for destination that is directly connected. The "route-to" would only be used to target not directly connected and the "SYN/ACK" packet reaches the client (because monitor arrive via tcpdump). And the client receives a packet out of context/order type he previously closed the three way handshake with google (spoof by proxy) and reaches another "SYN/ACK" when it resets the connection. Any idea where he might be going wrong? Att.