I'll hook myself into this discussion, as I recently did some
testing of SSHed AFP with a FreeBSD box running netatalk2.0. It's
probably not realy equal to what's being done with Apple's software,
but for testing and understanding what happens you have much more
possibilities in regards of logging and so.
Sorry, confused in my posting. One of those days. To many fires,
too many irons.
But yes, this is still an issue with how your NAPT engine operates.
Dan, if I understand you correctly you want to say that it could be
a problem in opening ports on the NATing router, or it even could
have problems with assigning the correct port addresses to the
responsible IP. NAT is a bad thing in any situation, but it will
take some more time 'til we get IPv6.
No, if I meant to say that I would have. That would be a mapping or
Many NA(P)T engines and routers are incapable of allowing traffic
flows between their NIs, and many novices just expect they will. An
instance of this issue is where you can't reach a service through
it's public IP address / WAN NI on an RFC1918 segment through the
same gateway. A SonicWall SoHo3 is an example where you see this not
working. A SonicWall TZ-170 is an example of it working. It depends
on how packet
some more of my thoughts...
When using AFP-over-SSH an SSH tunnel is being set up to the remote
end. That's the easy part and I think it's what the NAT sees, simple
SSH traffic. So first thing in debugging is checking if standard SSH
Typical NA(P)T firewalls also do state inspection.
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