Date: Fri, 07 Nov 2014 10:34:10 -0300 From: spiderslack <spiderslack@yahoo.com.br> To: freebsd-pf@freebsd.org Subject: doubt route-to pf Message-ID: <545CCA52.8090605@yahoo.com.br>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545CCA52.8090605>