Short version:
I'm having a problem with some sendmail programs refusing to acknowledge me
if I have my firewall's 113 (auth) port set to REJECT.
Long version:
I've had a couple pieces of mail sit in my mail spool for a full five days
before they finally got returned to me. Turns out, upon telnetting to the
remote machine's smtp port, that they were never printing a greeting
banner, and my sendmail reported a read error and failed (even though in
some cases, it was possible to send commands to the remote sendmail).
After flipping through archives of linux-net, I thought perhaps the remote
sendmail was having trouble because it wasn't getting a response from my
identd, that port being blocked via a REJECT rule (not DENY -- I checked :).
So I opened up the port, and voila, I could get a greeting. Strange thing
was, identd still wasn't running on my firewall, so I was confused --
shouldn't the two methods of "blocking" the packet (firewall and no daemon)
work in the same way?
Checking from a machine I actually had access to, I telnetted to my
firewall's auth port, and in both cases, telnet returned Connection
Refused, so it obviously wasn't a problem with all machines.
I privately emailed Glynn Clements, who from the posts I'd read, seemed to
have a pretty good handle on similar problems, and we hashed the problem
out a little more.
I learned that if no daemon is present, then a TCP RST packet is sent,
while with the firewall in place, an ICMP destination-unreachable packet is
sent. (I am letting those packets out.)
As far as I know, both these conditions should be returned to the userspace
program in the same way -- resulting in an error telling the remote host to
just give up. In the case of sendmail, dump the ident check and get on
with its business, but for some reason, that's not happening.
A quick perusal of the dumped sessions doesn't seem to indicate that
anything is wrong with the packets sent, but I'll put them here and hope
that any gurus out there can take a crack at it.
All dumps are taken from adsl-<garbage>, my firewall, with no special
snaplen (might the snaplen be too short?).
This pair of packets comes from a machine which does work, in the case of
no daemon listening:
19:32:20.406710 morel.campusclub.Princeton.EDU.7619 >
adsl-209-233-33-110.snfc21.pacbell.net.auth: S 3810532279:3810532279(0) win 512 <mss
1460>
4500 002c 5178 0000 3306 360b 8cb4 803d
d1e9 216e 1dc3 0071 e320 1bb7 0000 0000
6002 0200 78d1 0000 0204 05b4 0000
19:32:20.406970 adsl-209-233-33-110.snfc21.pacbell.net.auth >
morel.campusclub.Princeton.EDU.7619: R 0:0(0) ack 3810532280 win 0
4500 0028 4240 0000 ff06 7946 d1e9 216e
8cb4 803d 0071 1dc3 0000 0000 e320 1bb8
5014 0000 927a 0000
This pair of packets comes from one of the problem machine, also with no
daemon listening:
19:27:03.754789 math.Berkeley.EDU.2308 > adsl-209-233-33-110.snfc21.pacbell.net.auth:
S 175168000:175168000(0) win 4096
4500 0028 a632 0000 3206 b7c7 8020 b75e
d1e9 216e 0904 0071 0a70 da00 0000 0000
5002 1000 8726 0000 0000 0000 0000
19:27:03.755047 adsl-209-233-33-110.snfc21.pacbell.net.auth > math.Berkeley.EDU.2308:
R 0:0(0) ack 175168001 win 0
4500 0028 409c 0000 ff06 505d d1e9 216e
8020 b75e 0071 0904 0000 0000 0a70 da01
5014 0000 9713 0000
This pair of packets comes from the good machine, with the firewall up:
19:30:40.651900 morel.campusclub.Princeton.EDU.7557 >
adsl-209-233-33-110.snfc21.pacbell.net.auth: S 820943509:820943509(0) win 512 <mss
1460>
4500 002c 5166 0000 3306 361d 8cb4 803d
d1e9 216e 1d85 0071 30ee 9a95 0000 0000
6002 0200 ac63 0000 0204 05b4 0000
19:30:40.652125 adsl-209-233-33-110.snfc21.pacbell.net >
morel.campusclub.Princeton.EDU: icmp: adsl-209-233-33-110.snfc21.pacbell.net tcp port
auth unreachable [tos 0xc0]
45c0 005c 41da 0000 ff01 78bd d1e9 216e
8cb4 803d 0303 9071 0000 0000 4500 002c
5166 0000 3306 361d 8cb4 803d d1e9 216e
This pair of packets comes from the bad machine, with the firewall up:
19:27:41.290109 math.Berkeley.EDU.2330 > adsl-209-233-33-110.snfc21.pacbell.net.auth:
S 181824000:181824000(0) win 4096
4500 0028 c6c1 0000 3206 9738 8020 b75e
d1e9 216e 091a 0071 0ad6 6a00 0000 0000
5002 1000 f6aa 0000 0000 0000 0000
19:27:41.290323 adsl-209-233-33-110.snfc21.pacbell.net > math.Berkeley.EDU: icmp:
adsl-209-233-33-110.snfc21.pacbell.net tcp port auth unreachable [tos 0xc0]
45c0 0058 4129 0000 ff01 4ee5 d1e9 216e
8020 b75e 0303 19e1 0000 0000 4500 0028
c6c1 0000 3206 9738 8020 b75e d1e9 216e
091a 0071 0ad6
And this pair of packets went wee wee wee, all the way home. ;-)
I know nothing about the OS on the problem machines, except that one claims
to be "SUN-4/SS20-71 SUNOS-4.1.4" (from its DNS record). My firewall is
running vanilla 2.1.127, with the standard (I presume) firewalling and
masquerading options.
So -- can anyone help? I'll pass on more information, if it's necessary.
If I *do* get help, for extra fun and games, I'll also send my *other*
problem. Hee hee. <wink>
Please CC: me on any discussion, as I'm not subscribed to linux-net.
Many thanks,
Danek
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
