1. Home
  2. Networking Firewalls
  3. Netscreen 25 blocking Backup Server

Netscreen 25 blocking Backup Server

My company just purchased a disk based backup server (Unitrends DPU

2000) and it was installed on our LAN. Our LAN is connected to the Trust Zone on a Netscreen 25 (Hardware Version 4010(0) Firmware Version: 5.0.0 r 8.0). We have an SMTP Server connected to the DMZ Zone on the same Netscreen 25.

When the Backup Server attempts to run a backup on the SMTP server, I get a "partial connection check IP filters/firewall" error. Even with a policy allowing all traffic between the 2 zones, I get this error. Backups on servers in the Trust Zone run fine, so I've narrowed the problem down to the netscreen.

The Backup Server uses 2 ports during operation, 1743 for a "control channel" and 1744 for a "data channel". In viewing the error logs on the back up server I find the following "Cannot connect to IP XXX.XXX.XXX.XXX port 1743 Address is in use for channel 1743. channel 1743.

What is the problem I am not seeing?

Any help would be appreciated. Thanks

Scott

Reply to
I__Alone
Loading thread data ...

You're probably NATing out of your trust zone, perhaps because you have NAT on that interface. The backup software probably tries to connect back to the backup server directly, which since you're NAT'ed ends up talking to the DMZ IP of the firewall.

If you want to run NAT into the DMZ with this setup you'll need a VIP for that sevice.

The better solution is to turn NAT off on the interface, enable it on the trust -> untrust policies, and leave it off for the trust -> dmz policies. Same for dmz -> trust policies, you probably don't want or need NAT that way, depending on you architecture.

That's a bit of a guess though, what you really need to do is a flow debug and see exactly what the NS is doing with it.

-Russ.

Reply to
Somebody.

The error you are getting response to an error in the FTP protocol. The backup tool most likely uses FTP, if your netscreen is able to do connection tracking on FTP it doesnt recognize is because of its wierd ports. Try enabling deep inspection on FTP protocol and upgrading (if your running screenOS 4).

Wuvbear

Reply to
Wuvbear

Deep inspection is more likely to be the cause of the problem than the cure. If it's doing FTP on a non-standard port, he needs to make sure he selects "FTP" as the application. This will enable the ALG to work even though it's a custom service that isn't on port 21. And take of DI for that policy.

-Russ.

Reply to
Somebody.

My fault, your right

So that the solution :)!

Reply to
Wuvbear

Without quoting anything, we don't know which of the 3 different solutions that was offered turned out to be the correct one.

-Russ.

Reply to
Somebody.

Well, Russ, you nailed it right on. The Trust interface was NAT'ed and the backup client software was replying to the DMZ interface, to which it couldn't connect. While I couldn't create a VIP (you can only create a VIP on the untrust zone...with my version firmware anyways) a MIP was just what I needed. We use static IP's here in our small shop. After redirecting the client software to the MIP, I am a much happier man. I am backing up my SMTP server right now.

Thanks for the push in the right direction.

Reply to
I__Alone

Hey, glad to help.

Cheers!

-Russ.

Reply to
Somebody.

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.