[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TCP Reflection: Summary
Sorry, one final reply to self. Found the answer, albeit not the one I
was looking for, in the pf.conf manpage for 3.2. This information
should probably be reflected in OpenBSD's FAQ which describes a typical
"Note that all translation rules apply only to packets that pass through
the specified interface. For instance, redirecting port 80 on an
external interface to an internal web server will only work for
connections originating from the outside. Connections to the address of
the external interface from local hosts will not be redirected, since
such packets do not actually pass through the external interface.
Redirections can't reflect packets back through the interface they
arrive on, they can only be redirected to hosts connected to different
interfaces or to the firewall itself."
On Fri, 2002-11-01 at 18:58, Jason Dixon wrote:
> Sorry for the reply to self, but I found a solution. The following rdr
> solves the problem, but should it be necessary? Can someone explain to
> me why the default action of redirecting on the external interface,
> since we're routing between LAN's, shouldn't work?
> rdr on $int_if proto tcp from any to $server port 80 -> $webserver \
> port 80
> On Fri, 2002-11-01 at 18:29, Jason Dixon wrote:
> > Good news and bad news. Good news, I finally got tcp reflection working
> > (on 3.2) via the multiple nat/no nat/rdr rules. Turns out I had the
> > $server confused with the ext_if address, rather than the webserver.
> > Sounds stupid, but... well, I guess it is. :-P
> > Bad news. Defaulting back to a "normal" set of NAT rules (one for
> > "masquerading", one for port forwarding to the internal webserver), I'm
> > having difficulties with a typical DMZ setup. This time, the client is
> > on the 192.168.2.0/24 network, trying to reach the webserver on
> > 192.168.1.0/24 network, but being redirected through the external
> > interface (10.109.10.97). Every time I send a connection, the firewall
> > sends an immediate reset. No traffic on any of the other interfaces.
> > It does manage to work if I create a set of "reflection" rules for this
> > interface as well, but I thought that a DMZ didn't NEED this sort of
> > complex mangling. The routing is fine; I have no problems pinging the
> > webserver from the client... it's only when the packet attempts to hit
> > the external address for redirection that it gets reset.
> > Any ideas?
> > Thanks again,
> > Jason