Netscreen 500 - Zone to untrust

btray900 used Ask the Experts™

I have public IPs set up as MIPs to private IPs on the untrust interface. I have combed through all the policies and everything is set to any <--> any. However, I can not reach any of the MIPs from the servers being MIP'ed. The servers can browse any other site on the internet except sites hosted on the MIP'ed subet.

Nothing in the policies strike me as anything that would block the servers from browsing their own MIP'ed IPs.

Does anyone recognize the situation where a MIP can not access a MIP on a netscreen 500, but any other host on the internet can access the MIP and the MIP can access any other host on the internet.

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Hmm thats an unsual one.

If you create a global to global policy with any > any service any, DENY, Logging on.

You can then capture logs of all traffic that is being dropped by the firewall. Let me know if you see you private IP to MIP traffic in that log


What would a policy like that do to regular traffic?

To add more detail: the public range is it is applied to interface eth3.310 with an interface IP of There is a route in the routing table the shows up automatically for this subnet.

The MIPs are on the untrust interface in the range, but those IPs are no where else but the MIPs.

Such as:
MIP --->

The private space is There is a Cisco CSS doing some routing. The Netscreen has a static route for to (CSS).

From the Netscreen and CSS I can ping: (fw interface) (private route gw) (server)

I can not ping a MIP from the firewall or the CSS, I can only ping MIPs from the Internet.

I can access port 80 on the MIP via the Internet just fine.
A server in the private space (a different MIP) can access the Internet and the sourceis the defined MIP IP of

None of the private servers can ping or browse the MIPs. The CSS which has a static route of : (fw)

It seems like the translation and routing are not working right and that traffic from a MIP destined for a MIP is not routing properly.

I've tried any number of policies on various interfaces. I do have a any to policy for untrust to trust, this allows hosts on the internet to browse the MIP. I did turn logging on that and saw the normal traffic, I did not see any traffic when I tried to browse it from the private server.

The global deny policy should be the last policy on the list. It allows you to log all the traffic that does not pass any of the previous policies. This allows you to see what traffic is being dropped by your netscreen after all the policy rules have been processed.

Have you tried to run a traceroute either from the netscreen or a pc to see where that traffic is going?
You should be able to ping your MIP from inside the juniper by default so i suspect there may be a route statement or minor config error that is throwing everything off.

Are you familiar with the juniper debug commands? this is a good way to see exactly whats going on inside your netscreen on a packet by packet basis. Here is how you debug traffic from the command line.

set ff src-ip <ip of your pc> dst-ip <MIP ip address>
debug flow basic
clear db

... ping from your source ip to destination ip b4 continuing

undebug all (or press esc key twice)
get db str

You will then get information filtered by source and destination IP showing what is happening to your traffic.

Hope this helps!

Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!


Hmmm, thank you so much for the debugging help.

After pinging and checking out the stream, everything looks OK, routes found, policies permitting the traffic, then the end of each packet ends with:

  search route to (ethernet4/1.310,> in vr trust-vr for vsd-0/flag-3000/ifp-ethernet4/1.310
  [ Dest] 40.route>, to ethernet4/1.310
  route to
  nsrp msg sent.

The .98 is the CSS 11500. To me it looks like the traffic gets routed to the LB, because the subnet is behind it, and there is a static route on the FW to send traffic to the LB (.98).

So is the Netscreen not at issue but the Cisco CSS is?


Here's  all the info for one of the packets, in case I am reading the debug wrong:
****** 826862.0: <CustomerA/ethernet4/1.310> packet received [60]******
  ipid = 26358(66f6), @d7801114
  packet passed sanity check.
  no session found
  flow_first_sanity_check: in <ethernet4/1.310>, out <N/A>
  chose interface ethernet4/1.310 as incoming nat if.
  flow_first_routing: in <ethernet4/1.310>, out <N/A>
  search route to (ethernet4/1.310,> in vr trust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 28.route>, to ethernet4/1.310
  routed (x_dst_ip from ethernet4/1.310 (ethernet4/1.310 in 0) to ethernet4/1.310
  policy search from zone 1004-> zone 1004
 policy_flow_search  policy search nat_crt from zone 1004-> zone 1004
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip, port 19792, proto 1)
  No SW RPC rule match, search HW rule
  Permitted by policy 174
  No src xlate   choose interface ethernet4/1.310 as outgoing phy if
  check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet4/1.310
  vsd 0 is active
  no loop on ifp ethernet4/1.310.
  session application type 0, name None, nas_id 0, timeout 60sec
  service lookup identified service 0.
  flow_first_final_check: in <ethernet4/1.310>, out <ethernet4/1.310>
  existing vector list 21-c4183f0.
  Session (id:247602) created for first pak 21
  route to
  wait for arp rsp for
  nsp2 wing prepared, not ready
  cache mac in the session
  search route to (ethernet4/1.310,> in vr trust-vr for vsd-0/flag-3000/ifp-ethernet4/1.310
  [ Dest] 40.route>, to ethernet4/1.310
  route to
  nsrp msg sent.
Ok so it looks like you have the cisco managing your public IP addresses and the juniper using said ips statically configured on the untrust interfaces or as MIPs. Your analysis of the debug log is correct. The traffic is being routed to the correct destination and the relevant policies are in place to allow it to pass, but something in your cisco is preventing traffic from one interface from reaching any of the other ips ( etc)

If it was a juniper router i would say there is no trust-trust policy allowing ->, but there is an untrust -> trust policy allowing <internet - >

I am not to familiar with the ins and outs of cisco routers, but that might be where you want to start looking for issues or misconfigurations.


Very helpful.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial