Screen OS

Greetings.

I have a pair of SSG140 firewalls set up in NSRP (Yes, I know they're old). I have two subnets on the same virtual router and in the same zone (192.168.42.0/24 and 172.20.0.0/16) which are used by machines on the network. However, if I try to transfer a file from a computer on the 192.168.42.0/24 from the 172.20.0.0/16 (or vice versa) through the SSG140, it gives me an error (if it takes more than about 10 seconds to transfer) and Windows says the file is no longer available.

I thought maybe it was a problem with our vintage network switches, so I connected it all up to a brand new switch. Still no dice. I then swapped the primary and backup router and it still does the same thing. If the computers are on the same subnet there is no problem. If I use my switch for subnet routing, it works fine. So I'm not quite sure what the culprit may be, except that it is a problem with the Juniper itself. I have firmware 6.3.0r23.0 installed on both of them. I'm not ready to hard reset them to test it on a black slate, but I may get there if I cannot find a solution. I've used SSG140s for a lot of years and I've never had this problem. It seems odd that both would have this issue if it were hardware related - which leads me to believe that it is a configuration problem or possibly a firmware related obstacle.

Thanks.

Sounds like a possible session timeout issue.  Run a debug flow basic to make sure that the traffic is flowing correctly.

Hello,

Enable the 'flow debugs' as below:

set ff src-ip 192.168.42.x dst-ip 172.20.0.y   (or any test PC IPs)

set ff src-ip 172.20.0.y dst-ip 192.168.42.x

set db size 4096

debug flow basic

Now initiate the file transfer between above two IPs and once it fails, stop the debugs with 'undebug all' and attach the output of 'get db stream' so that we can have a look.

Regards,

Rushi

I'm not totally sure what all of this means since I've never had to run a debug before, but it looks as though it stops processing packets properly around line 100698:

**** pak processing end.
  packet dropped, first pak not sync

After that, it never recovers and the file copy stops.

Just before that happens, it receives a packet and says that there is no active session between the two machines and the route has apparently been lost. So maybe it is a session timeout as you suggested? If it is, what can I do about it?

192.168.42.68 is on Eth0/8 and 172.20.250.1 is on Eth0/9.

I tried to copy a 3GB file from 172.20.250.1 to 192.168.42.68.

Smaller files, under 10MB, seem to copy just fine.

Thanks.

Attachment(s)

jnpr-debug3.txt   4.00 MB 1 version

I added a trust->trust policy just out of curiosity and it shows "age out" at about 20 seconds.

Looks like the return traffic is not passing through the firewall.  Run a traceroute from the 172 device and see if it passes through the firewall.

Oh. I know what's happening now. The initial problem I had yesterday was a result of the two machines being on different subnets and ALSO utilitizing different routers for their primary gateways. We have an Adtran that is currently the production router and the Junipers are in limited use for testing and will take the place of the Adtran once we are assured in their operation. One of my test machines has an IP from both subnets and so I think it was trying to send traffic back to the initiating machine by using the IP with the same subnet as the machine sending the request, but that computer was just dropping that traffic because it wasn't expected from that IP. Once I removed the 192.168.42.x subnet from my test machine, the file transferred normally because both of those machines are using the Junipers are their primary gateway. Your response made me realize what was occuring. Well done.

I'm not quite sure why Windows will respond to a request from a particular IP on another subnet by using a NIC on that same subnet instead of just responding on the same IP that received the request. I guess it has something to do with OSPF, but it doesn't work in this case. Granted, it was still my fault.

Thank you.

All devices will do that.  When it sends the reply, it has to generate a new packet and will do a route lookup.  Connected routes are always prefered over other routes.