Comment 4 for bug 532286

Thierry, as usual, thanks for your rapid response/attention to these issues.

Good suggestion; I will try using a linux machine to connect from 192.168.1.x, which is my home network. First, let me point out that Win XP and Mac OS X machines on various networks have been unable to connect to the Samba server -- I only tested linux from one location, but will try your suggestion this weekend.

128.83.133.100 is routable from 216.110.51.120, but 192.168.1.64 is not, as this is a private network using NAT. The external address for 192.168.1.64 is 99.91.6.24, and this is routable from 216.110.51.120. Using an ssh proxy on the firewall for the Samba server (i.e. using iptables to route port 2222 on the firewall to port 22 on the samba server), I can ssh from the Win XP machine directly to the Samba server, and using a windows SSH FS tool called ExpanDrive, can map and use drives over ssh; i.e. other TCP/IP protocols do work from the (firewalled) 192.168.1.64 Windows desktop to the (firewalled) Samba server.

Re: server logs:
The only thing in the server logs regarding 99.91.6.24 are the ssh connections:
root@data:/var/log# rgrep '99.91.6.24' *
auth.log:Mar 3 21:07:10 data sshd[26848]: Accepted password for pgoetz from 99.91.6.24 port 1085 ssh2
auth.log:Mar 3 21:21:51 data sshd[26920]: Accepted password for pgoetz from 99.91.6.24 port 1118 ssh2
(etc. -- several ssh connections listed)

Note that the new Samba server keeps track of all connection attempts (mostly unfriendly probes) and creates individual log files for them:
  log.__ffff_82.64.100.254 (attempted hack)
  log.ea103 (legitimate internal desktop)
  log.lizard (linux desktop used for testing)
  (etc.)

Log files exist even for failed connection attempts, but none exists for 99.91.6.24.