In article <jsteinaker.3rbnbc@no-mx.forums.novell.com>, Jsteinaker
wrote:
> Mmm, it's not the best scenario. If there's a "right" solution, let's
> try it first. Can you explain me the idea?
>
The right way is to target the filter exceptions you need. Using
Filter Debug techniques is how I would go about it. (I show some
examples in my BMgr filtering book). The idea being that you show
packets being filtered, so you know what filter exceptions to open up.
FTP is not the simplest application to allow with filter exceptions,
since it uses both control and data ports. The default stateful FTP
exceptions take that into account in their design, but once you vary
from the default ports I wonder if you have real problems making
stateful exceptions? Anyway, you could open up the control port to
the target server address in one exception, and try making it stateful.
Or a pair of non-stateful exceptions, one with non-standard FTP dest
port, and the other with that port as source port. The data portion
could be a problem for you, but you might allow all IP from the target
server, and replies back out.
PKTSCAN on the server, with Wireshark on a PC to read the data easily
might be useful for seeing what ports are being used.
Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to
http://www.craigjconsulting.com ***