tcp port sticks in closing state

2004-03-09 Thread daemon
Hi all,

I have a strange question that is probably more a tcp thing than FreeBSD,
but you all have helped me so much in the past that I thought I'd start
here.

I am running FreeBSD 5.2.1 at home with postfix-2.0.18,1 from ports. When
I send an email from my work (red hat 9, qmail), which is behind a
Watchguard Firebox 700 doing NAT and using their smtp-filter (i'm the
sysadmin at work, so any bad there is all me), to my home address it
causes the freebsd machine to sit in the the following state (from a
netstat -an | grep 25):

tcp4   0  0  192.168.1.2.25 61.XX.X.XX.28709   CLOSING
tcp4   0  0  192.168.1.2.25 61.XX.X.XX.28708   CLOSING

This ties up the smtp port and any further attempts to connect from
anywhere on the net yield:

421 SMTP service not available, closing transmission channel

To get this I have to send a bunch of emails (say 4 or more) and the first
two always get through. When I send a bunch of emails from any other
address (yahoo, etc) this does not happen.

I did a tcpdump -i fxp0 and greped for the port of one of these sessions
and see:

21:45:18.424512 chinook.myhost.com.smtp  61.XX.X.XX.28709: F
2504912170:2504912170(0) ack 2923328197 win 65535 (DF)
21:47:26.436486 chinook.myhost.com.smtp  61.XX.X.XX.28709: F
2504912170:2504912170(0) ack 2923328197 win 65535 (DF)
21:48:30.442449 chinook.myhost.com.smtp  61.XX.X.XX.28709: R
2504912171:2504912171(0) ack 2923328197 win 65535 (DF)

So ... what's going on here? To me it looks as if chinook.myhost.com is
trying to ACK back to the server at my work and not getting an answer.
From what I googled the tcp connection takes 5 mins to die in the closing
state. But in the meantime my mail server is not able to receive messages.
Should it do this? This seems like a bad thing and an way of DOSing
someone's mail system.

Any thoughts? Any better places to post?

Thanks in advance,

August Simonelli



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp port sticks in closing state

2004-03-09 Thread daemon
 Hi all,

 I have a strange question that is probably more a tcp thing than FreeBSD,
 but you all have helped me so much in the past that I thought I'd start
 here.

 I am running FreeBSD 5.2.1 at home with postfix-2.0.18,1 from ports. When
 I send an email from my work (red hat 9, qmail), which is behind a
 Watchguard Firebox 700 doing NAT and using their smtp-filter (i'm the
 sysadmin at work, so any bad there is all me), to my home address it
 causes the freebsd machine to sit in the the following state (from a
 netstat -an | grep 25):

 tcp4   0  0  192.168.1.2.25 61.XX.X.XX.28709   CLOSING
 tcp4   0  0  192.168.1.2.25 61.XX.X.XX.28708   CLOSING

 This ties up the smtp port and any further attempts to connect from
 anywhere on the net yield:

 421 SMTP service not available, closing transmission channel

 To get this I have to send a bunch of emails (say 4 or more) and the first
 two always get through. When I send a bunch of emails from any other
 address (yahoo, etc) this does not happen.

 I did a tcpdump -i fxp0 and greped for the port of one of these sessions
 and see:

 21:45:18.424512 chinook.myhost.com.smtp  61.XX.X.XX.28709: F
 2504912170:2504912170(0) ack 2923328197 win 65535 (DF)
 21:47:26.436486 chinook.myhost.com.smtp  61.XX.X.XX.28709: F
 2504912170:2504912170(0) ack 2923328197 win 65535 (DF)
 21:48:30.442449 chinook.myhost.com.smtp  61.XX.X.XX.28709: R
 2504912171:2504912171(0) ack 2923328197 win 65535 (DF)

 So ... what's going on here? To me it looks as if chinook.myhost.com is
 trying to ACK back to the server at my work and not getting an answer.
From what I googled the tcp connection takes 5 mins to die in the closing
 state. But in the meantime my mail server is not able to receive messages.
 Should it do this? This seems like a bad thing and an way of DOSing
 someone's mail system.

 Any thoughts? Any better places to post?

 Thanks in advance,

 August Simonelli



Follow up:

the outgoing mail was relayed through a Red Hat 9 / qmail box (hiding
exchange 2000). when i removed the relay, the problem went away. maybe i
missed a patch? maybe it's the private ip that the box is using (dmz -
screwed up nat rule?)? not sure ... but it'll be fun to test. as this is
probably not an issue for this list i won't post anymore follow-ups ...
please contact me directly if you are interested in any more info!

august

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]