From: Daniel Hartmeier <[EMAIL PROTECTED]>
Date: Mon, 26 Jan 2004 23:23:01 +0100
On Sun, Jan 25, 2004 at 03:50:22PM -0800, Scott L. Burson wrote:
synproxy doesn't work with some nat translations (never did), for instance
nat on $ext_if from 10.0.0.0/8 to any -> 62.65.145.30
pass in on $int_if from 10.0.0.0/8 to any synproxy state
Well, I'm not doing synproxy on the outgoing connections, but do have `rdr'
on some, but not all, of the relevant incoming ones.
When 10.1.2.3 connects to 129.128.5.191, synproxy will first handshake
with the client (which works), but then replay the handshake with
129.128.5.191 through $ext_if, without applying the nat translation.
If this is what happens, it should be easy to spot with tcpdump -nvvvS
running on all interfaces, capturing one failing TCP connection attempt.
The handshake packets generated by synproxy are always passed
unconditionally (without matching/creating state or getting translated
further on subsequent interfaces).
Oh wait, here's something interesting! The relevant rules look like:
pass in log on $if_dsl reply-to $dsl inet proto tcp from any to any \
port ftp flags S/SA synproxy state
Now that you suggest looking on all interfaces, I see that the synproxy
handshake is going out on the _wrong interface_ (ignoring `reply-to $dsl').
Specifically, it's being sent according to the default route, which goes out
the cable modem interface. Maybe somehow this happens under some
circumstances but not others? Or conceivably, it's always been happening
this way, but for some reason, the packets were being delivered before by
the ISP, and now they're not. It would be a bizarre coincidence, though, if
that had changed exactly when I rebooted the firewall.
I'll bet it has something to do with the order in which the routing table
entries are created. _This_ I could believe might have changed as I
completed the firewall setup -- or there could even be something
nondeterministic going on.
So, what to do about it? Is this already being fixed? Should I enter a bug
report somewhere?
-- Scott
