Screen OS

Hi all - hoping for a little bit of peer advice here:

i have an SSG 550M 'hub' fw which tunnels out to several remote internet based juniper fw's.  We create tunnels between them and route the traffic down those tunnels.  I'm having an issue with the newest one that ive set up and im not quite sure why:

below is a screen shot from my attempt to ping out from a device behind that hub fw to a device out on the remote network.  I should note too that the tunnel itself does appear to be up and functioning just fine its just a matter of the traffic not being allowed out for some reason.

Youll see that traffic to the .65 passes on rule 22 which is a rule allowing the whole 192.168.220 net to talk to the 192.168.222 net on a variety of ports (ping included).  This traffic to .83 SHOULD be hitting on that same rule and i verified that the network object in use for the 222 net is subnetted as a /24.  What am i missing/forgetting here? why is this new traffic being blocked by the global drop (rule 80) and not passing on the rule that the other one is?

any help, advice or suggestions to try would be greatly appreciated

You would need to run a debug flow basic to see how the traffic is being processed.  It's possibly an issue with the routing.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB23844#basicdebug

I agree this is most likely a missing or incorrect route.  Run this on the cli

get route prefix 192.168.222.0/24

confirm that the whole subnet is correctly pointed to the expected tunnel interface and no more specific routes are in place that would direct portions elsewhere.

thank you - so in this case actually this SSG 550 does have MULTIPLE routes for various segments of the 192.168.222 network...in this case its 192.168.222.80/28 that i want to route out via my tunnel. I had/have a feeling that something is up with the routing but when i look in the screen os gui it does show my route for 192.168.222.80/28 pointed to the remote internet network is up and active...The subnet below this one is 192.168.222.72/29 which is being routed out a different tunnel interface and is seperate from this one.  we have various segments of the 222 network out at our deployed sites that all tunnel back.

1: debug flow basic will give you all the details, why it's getting blocked.

2: In your logs there some Source NAT when it's working and there is no nat when it's not, not sure if this is relevant.

3: can you check the policy id and the route from the firewall's CLI : as below :

   get policy from <source zone> to <destination zone> src-ip <source-ip> dst-ip <destination ip>

   get policy id 18

   get policy id 3

   get route ip <ip which is not working>

   get route ip <ip which is working>

Thanks,

Vikas

Please confirm that the tunnel interface is in the same zone as the other tunnels matching the destination zone in the security policy.

bingo this was my issue (tunnel interface in wrong zone)....thank you very much i really appreciate this assistance