Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 09 Jul 2012 18:31:55 -0700
From:      Hao Bryan Cheng <hbcheng@berkeley.edu>
To:        <freebsd-pf@freebsd.org>
Subject:   Question regarding packet forwarding and Squid
Message-ID:  <7b10a675fc6b44b4b93597d97036de31@berkeley.edu>

next in thread | raw e-mail | index | archive | help
Hello all,

I am working on converting a captive portal system from ipfw to pf (in
order to support port-block allocation in many-to-one NAT) on systems
currently running FreeBSD 8.2.

Most of the firewall rewrite went without incident. However, I am having
trouble replicating the fwd functionality of ipfw in pf.

Our ipfw firewall uses the fwd rule to send packets from the private side
of the portal to a squid instance running on 127.0.0.1:3128. From there,
squid runs our url_rewrite script. The nice thing about this setup is that
the fwd rule does not rewrite either the destination IP or port of the
packet, meaning that the url_rewrite script can easily extract this
information from the input line that squid provides (myip corresponding to
the destination IP address of the original HTTP request). We then add the
IP address to a firewall table to grant HTTPS access to the destination
host bypassing squid entirely.

I was able to get traffic into squid via pf using a rdr rule. However this
rule rewrites the destination IP and port of the request which means that
the url_rewrite script is no longer aware of the original destination IP.
While there are several options for changing the url_rewrite script to
accommodate this change, I would like to avoid unnecessary (and redundant)
nameserver lookups.

Is there a rule in pf that behaves similarly to ipfw's fwd rule? I have
heard mentions of a divert-to rule, but I was unsuccessful in finding any
official documentation on the subject anywhere online.

Any help would be greatly appreciated.

Thanks,

Hao Bryan Cheng



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b10a675fc6b44b4b93597d97036de31>