• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1190
  • Last Modified:

Netscreen 500 - Zone to untrust

Hi,

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.

Thanks!
0
btray900
Asked:
btray900
  • 4
  • 3
1 Solution
 
Sanga CollinsSystems AdminCommented:
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
0
 
btray900Author Commented:
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.
0
 
Sanga CollinsSystems AdminCommented:
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!

0
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

 
btray900Author Commented:
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?

0
 
btray900Author Commented:
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.
0
 
Sanga CollinsSystems AdminCommented:
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 1.1.1.98/32 from reaching any of the other ips (1.1.1.103/32 etc)

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

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.
0
 
btray900Author Commented:
Very helpful.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now