Knowing the network geometry, routing and address spaces would be
most helpful if you expect a better response.
In my case it's:
Where's the PIX in that? Are you the poster I was talking to under
No. He's someone else. This is my reply...
On Aug 11, 2005, at 9:28 AM, Dan Shoop wrote:
There's probably no bug, the problem is most likely with your PIX,
though this is common with NAT'ed network devices in general (in
your case your "DMZ".) If you take the PIX out of the picture,
place your XServe (on a switch) behind your router but before your
PIX, and give it a public IP (like a real DMZ) it should work just
Well, yeah, and it does. But that's not what I need.
Well that's too bad b/c that's how FTP and NAT work together. Or
should I say don't FTP was NEVER designed for use in NAT environments.
Apple says what I need "should work", so I just want to confirm
that: Is *anyone* having success with secure afp to any type of
Well this isn't dependent on anything from Apple but rather how your
NAPT server operates, so it's outside Apple scope. Yes it /should/
work assuming you have a real and proper NAPT device, but those are
FWIW, I do think it's a bug at least that turning on verbose logging
for ssl breaks secure afp (try adding "LogLevel DEBUG3" to
/etc/ssh_config and attempt a secure afp connection; it'll cause
connection attempts to time out -- unless it's just me, but I'll
SSL isn't used for secure AFP, ssh is. Teh above debug line doesn't
affect SSL at all. What are you talking about?
iWiring provides systems and networks support for Mac OS X, unix, and
Open Source application technologies at affordable rates.
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden