[CLUE-Tech] Feeble Mind

[Keith Hellman]

Hello all:

I ran across a strange connectivity problem in my place of work this
past week.  Thought I would simply post the symptoms here and see if the
resident networking gurus have any insights.

I will avoid details such as machine names and ISPs, instead I'll stick
to just the facts:

- We have a POP email server hosted for us by a third party, we'll call
  this server A.
- We have a DSL/Firewall appliance routing us between an internal
  network (192.168.123/24) and the outside world.

The issue is that a particular workstation - only recently setup to be a
user workstation requiring access to A - simply cannot hit A for the all
the network twiddling we do.  During troubleshooting we connected the
problematic workstation into the same hub as a working machine.  I'll
call these boxes P=problem machine, and W=working machine.  Both are
running Red Hat 7.3 (bleach!).  Here are the symptoms:

- There are no firewall rules on P (iptables -L lists all ACCEPT)
- P can ping A, P can traceroute to A - both with identical results to W
- P can surf the web - no problemo
- P can telnet into a yahoo.com mail server - no problemo
- P tries a telnet session to A with 'telnet A pop3' or 'telnet A smtp'
  and NEVER connects (this is the PROBLEM).
- W can do both telnet tests - no problemo
- If W assumes P's IP, W can do both telnet tests - no problemo
- Both P and W produce the same nmap results against A:  that being that
  pop3 and smtp are open.

I would also point out that both machines resolve A to the same IP.

So there you have it.  Our best guess at work is that the
DSL/NAT/Firewall is 'randomizing' the same source port for the outbound
P connections based on P's MAC (and perhaps the destination port), and
that this source port is somehow being blocked by a firewall rule at our
ISP.  At any rate, that's the best guess we can come up with (we're
programmers, not network gurus).

I could kick myself now for not testing W's IP on P - I can do that
quickly enough Monday morning.  The thing that puzzles me is the nmap
result.  I'm not sure if nmap actually goes through a full fledged
handshake when it is scanning (-sT option), if not and the suspect
firewall rule is imposed after the handshake, then the symptoms above
are plausible - otherwise I really am losing my mind.

At any rate, I've reported all these symptoms to our mail server
maintainers - I just figured some of you would like a little bone to
chew on this weekend, and this one seems to have a lot of grissle.  If
anyone has additional tests they think I should perform, let me know and
as long as it is not ripping the NIC out of P, I'll be able to report
back the results.  If anyone would like to know how this is finally
resolved, I'll be happy to keep you updated off list (if there's a ton
of discussion, I'll just keep the list updated).

-- 
Keith Hellman                             #include <disclaimer.h>
kehellman at yahoo.com               from disclaimer import standard