On Feb 9, 2008 8:03 PM, Jeffrey Goldberg <jeffrey at goldmark dot org> wrote:
> I've got one particular host on a LAN (sis0) that is trying to talk to
> a machine on the DMZ, but all TCP traffic appears to be blocked by
> this very early set of "rules"
> @29 skip 1 in proto tcp from any to any flags S/FSRA
> @30 block in log quick proto tcp from any to any
> Here are a couple of log entries
> Feb 9 15:09:12 firewall ipmon: 15:09:12.276053 sis0 @0:30 b
> -> 66.XXX.XXX.20,25 PR tcp len 20 52 -AF IN
That had ACK FIN set, so it was just closing a connection after the
state table had already closed it.
> Feb 9 15:09:54 firewall ipmon: 15:09:54.174472 sis0 @0:30 b
> -> 66.XXX.XXX.20,25 PR tcp len 20 64 -A IN
And that's an ACK that doesn't match an existing state.
> This doesn't look like the default deny rule since it is so early. So
> I am guessing that there is something about a tcp packet with flags
> that don't match S/FSRA that is considered worth blocking right away.
If SYN isn't set, it's not initiating a new connection, and if it hits
that point in the rules it's not in the state table. TCP connections
are always initiated with only SYN out of FIN, SYN, RST, and ACK set.
The remote responds back with a SYN ACK, and the client responds to
that with an ACK. That's the three part initial TCP handshake. Because
SYN isn't set and it doesn't match the state table, it appears to be a
spoofed/crafted packet. That's why these are getting blocked, m0n0wall
doesn't allow anything not matching the state table that isn't
initiating a new connection. What you're likely seeing is this:
It's more likely you have a different issue, and see this and think
it's related when it probably is not.
The dropped FIN ACK is definitely not causing you any connection
problems (at that point it was done and closing the connection), the
blocked ACK could have but it's hard to say.
You can't telnet to outside machines on port 25 from that host?