Netscreen 500 - Zone to untrust

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 1.1.1.96/27 it is applied to interface eth3.310 with an interface IP of 1.1.1.97. There is a route in the routing table the shows up automatically for this subnet.

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

Such as:
MIP 1.1.1.103 ---> 10.10.1.200

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

From the Netscreen and CSS I can ping:
1.1.1.97 (fw interface)
1.1.1.98 (private route gw)
10.10.1.200 (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 1.1.1.103 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 1.1.1.111.

None of the private servers can ping or browse the MIPs. The CSS which has a static route of :
0.0.0.0 0.0.0.0 1.1.1.97 (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 1.1.1.103 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!

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, 1.1.1.103->10.10.1.200) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet4/1.310
  [ Dest] 40.route 10.10.1.200->1.1.1.98, to ethernet4/1.310
  route to 1.1.1.98
  nsrp msg sent.

The .98 is the CSS 11500. To me it looks like the traffic gets routed to the LB, because the 10.10.1.0 subnet is behind it, and there is a static route on the FW to send 10.10.1.0 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.
  ethernet4/1.310:10.10.1.200/11->1.1.1.103/1,1(8/0)<Root>
  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, 10.10.1.200->1.1.1.103) in vr trust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 28.route 1.1.1.103->1.1.1.103, to ethernet4/1.310
  routed (x_dst_ip 1.1.1.103) 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 1.1.1.103, 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
  flow_first_install_session======>
  route to 1.1.1.103
  wait for arp rsp for 1.1.1.103
  nsp2 wing prepared, not ready
  cache mac in the session
  make_nsp_ready_no_resolve()
  search route to (ethernet4/1.310, 1.1.1.103->10.10.1.200) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet4/1.310
  [ Dest] 40.route 10.10.1.200->1.1.1.98, to ethernet4/1.310
  route to 1.1.1.98
  nsrp msg sent.

Very helpful.