Who eats my ACK-packet

I have several sevices running om my Fedora core 3 (ssh, http, smtp).
All but smtp work on the interface that connects to the internet (even
if I take down the firewall). All including smtp work on the interface
facing the local network.

Using tcpdump on the client and the server machine I've concluded that
the SYN packets gets through and the SYN/ACK is seen on the remote
machine. The ACK never gets back to the server.
Netstat on the server shows SYN_RECV. It seems there is a firewall
somewhere that eats this packet but I have no way of finding out where
this FW is. My IPS claims they have no FW on that line and the FW in
my zyxel ADSL modem is disabled.

The question is, is there a way to determine where this packet is
lost?

Greetings,
Jarek

In article <(E-Mail Removed) >,
Jarek Luberek wrote:

>I have several sevices running om my Fedora core 3 (ssh, http, smtp).
>All but smtp work on the interface that connects to the internet (even
>if I take down the firewall). All including smtp work on the interface
>facing the local network.

OK, let's verify that the "local networK" is a real network - if so, that
says you did follow the required steps to get the daemon to listed on an
external interface. All of them? See the RELEASE-NOTES that come with
Fedora, and the Sendmail-FAQ.

>Using tcpdump on the client and the server machine I've concluded that
>the SYN packets gets through and the SYN/ACK is seen on the remote
>machine. The ACK never gets back to the server.

meaning the third of the three-way handshake (SYN, SYN/ACK, ACK).

>Netstat on the server shows SYN_RECV. It seems there is a firewall
>somewhere that eats this packet but I have no way of finding out where
>this FW is. My IPS claims they have no FW on that line and the FW in
>my zyxel ADSL modem is disabled.

I'd be wanting to verify ISP port blocking. A lot of ISPs are now
blocking port 25 except to/from their own mail servers because of the
windoze zombie problem. Must admit that I haven't seen it done that
way before - generally they completely block the port, and all you see
is a SYN and RST.

>The question is, is there a way to determine where this packet is lost?

I'd be playing with tcptraceroute http://michael.toren.net/code/tcptraceroute/
netcat (at any sunsite mirror) and others, crafting up some interesting
packets with various flags and TTLs.

Old guy

(E-Mail Removed) (Moe Trin) wrote in message news:<(E-Mail Removed)>. ..
> In article <(E-Mail Removed) >,
> Jarek Luberek wrote:
>
> >I have several sevices running om my Fedora core 3 (ssh, http, smtp).
> >All but smtp work on the interface that connects to the internet (even
> >if I take down the firewall). All including smtp work on the interface
> >facing the local network.
>
> OK, let's verify that the "local networK" is a real network - if so, that
> says you did follow the required steps to get the daemon to listed on an
> external interface. All of them? See the RELEASE-NOTES that come with
> Fedora, and the Sendmail-FAQ.

Well, I found out the hard way.

>
> >Using tcpdump on the client and the server machine I've concluded that
> >the SYN packets gets through and the SYN/ACK is seen on the remote
> >machine. The ACK never gets back to the server.
>
> meaning the third of the three-way handshake (SYN, SYN/ACK, ACK).
Yes.

>
> >Netstat on the server shows SYN_RECV. It seems there is a firewall
> >somewhere that eats this packet but I have no way of finding out where
> >this FW is. My IPS claims they have no FW on that line and the FW in
> >my zyxel ADSL modem is disabled.
>
> I'd be wanting to verify ISP port blocking. A lot of ISPs are now
> blocking port 25 except to/from their own mail servers because of the
> windoze zombie problem. Must admit that I haven't seen it done that
> way before - generally they completely block the port, and all you see
> is a SYN and RST.
Searching google groups, I've found one other person having this problem
but there was no followups.

> >The question is, is there a way to determine where this packet is lost?
>
> I'd be playing with tcptraceroute http://michael.toren.net/code/tcptraceroute/
> netcat (at any sunsite mirror) and others, crafting up some interesting
> packets with various flags and TTLs.
Thanks for that info. Will try it. I've tried tcptraceroute which says that
port 25 is blocked but I don't know how to figure out whos blocking it.

> Old guy

/jarek

In article <(E-Mail Removed) >, jarek wrote:
>(E-Mail Removed) (Moe Trin) wrote in message
news:<(E-Mail Removed)>. ..

>> that says you did follow the required steps to get the daemon to listed
>> on an external interface. All of them? See the RELEASE-NOTES that come
>> with Fedora, and the Sendmail-FAQ.
>
>Well, I found out the hard way.

Don't feel bad - the reason it's in the FAQ is because countless people
have been caught by it.

>> Must admit that I haven't seen it done that way before - generally they
>> completely block the port, and all you see is a SYN and RST.
>
>Searching google groups, I've found one other person having this problem
>but there was no followups.

Same ISP?

>Thanks for that info. Will try it. I've tried tcptraceroute which says that
>port 25 is blocked but I don't know how to figure out whos blocking it.

Try the tcptraceroute to port 25, and note where things stop. Then try
again, but try to reach a user-land port, such as nearly anything over
1025.

Old guy