Hi pf crew,
I have been working on a device that can terminate a simple IPIP
tunnel back to a proxy service that the ISP I work for sells as a service
to customers in our AS that want to have the content filtered { pr0n and
such }. The proxy device excepts a IPIP tunnel and a acl on a Krisco
along with a Tunnel interface makes this magic possible. Basically all
clients that have the service are source routed to the filter service over
the tunnel for port { 80, 443 } and the device either gives back a blocked
screen asking for a password to accept the pr0n site or passes the traffic
onto the Internet and the encapsulation of the tunnel is riped off and the
traffic travels like normal back to the customer | BUT not back across the
tunnel. Today we got the IPIP tunnel up on a OpenBSD pf box using a gif
interface and a route-to for tcp port { 80, 443 }. Problem is the traffic
leaves the gif0 interface but comes back in on the $ext_if and gets
blocked. The work around was to
pass in quick on $ext_if inet proto tcp from any port { 80, 443 } to
$customer keep state.
but this has a major flaw in that anyone could spoof src_port { 80, 443 }
and get in to the customer. I was looking through the archives and found
http://www.benzedrine.cx/pf/msg01181.html
We would like to be able to extend our service outside of our AS to other
customers and would like to sell them a very l33t OpenBSD all in wonder
appliance. For now the only thing I can come up with is a tunnel box in
front of a firewall but this is really cluttered looking in my lab. I
have seen people talking about allow-opts but I'm not sure that IP options
is what I am looking for, maybe it is?. Anyone have a suggestion for me?
I know what I am asking for is a bit off beat but that is how the
filtering service works.
Thanks
Jason Houx
