[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rdr, nat to a internal webserver

On Thu, May 06, 2004 at 04:53:25PM +0200, Wolfgang Pichler wrote:
> This also works - but it
> seems that the firewall then isn't translating the request back to the
> right address
> Can something like this be done with pf  - or do i need something else ?
The additional nat on the internal interface should work as you want it
to. You should see two state entries created for each connection, pfctl
-ss should show
  $ext-if tcp <- $ext-addr:80 <- $client:$random
  $int-if tcp $client:$random ->$proxy ->
To debug, run tcpdump on the external and internal interface of the
OpenBSD box, you should see the TCP SYN arrive on the external as
$client:$random -> $ext-addr:80, then leave on th internal as$proxy ->
Then tcpdump on, you should see the TCP SYN arrive as$proxy ->, and the SYN+ACK leave as ->$proxy.
Then on the OpenBSD box again, on the internal interface, you should see
the SYN+ACK arrive as ->$proxy and on leave
on the external interface as $ext-addr:80 -> $client:$random.
Depending on where in this chain things fail, check whether both the rdr
rule on the external and the nat rule on the internal interface are
actually matched and used (pfctl -vsr shows rule matches and pfctl -vss
states with packet counters).
Enable debug logging with pfctl -xm, check /var/log/messages. If you get
state insertion errors, the two states have conflicting address:port
tuples (might happen if $client is within 172.17. as well).
In short, "seems not to translate" is much too vague, you'll have to
follow the packets through each host, and find out where precisely
things go wrong.
And, finally, you'll have to test from a real external client (on the
external interface side of the firewall), otherwise the setup won't
work, see the PF FAQ section about redirection and 'reflecting'
connections if that's what you have been doing.