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 Thanks, J. 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 > > > >
