ScreenOS Firewalls (NOT SRX)
Reply
Contributor
Stan-Gobien
Posts: 44
Registered: ‎01-15-2009
0

Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

Hi I have a small problem (not really a problem, but it annoys me).

On my netscreen 25 box i have ping enabled on both interfaces that are in use (eth1 & eth3). When i do a ping from local network to the LAN ip of the netscreen i get reply:

 

ping 10.1.5.254: Antwoord van 10.1.5.254: bytes=32 tijd=2 ms TTL=64

 

However when i do a trace route to a public IP (or even to a routed trust network), the 1st hop in the route (the netscreen is the 1st hop) shows as * * *

 

tracert 195.130.130.5: 1 * * * Time-out bij opdracht. 2 2 ms 2 ms 2 ms *******.adsl-static.isp.belgacom.be [******] 3 12 ms 14 ms 28 ms ******.adsl-fix.skynet.be [******] .... and so on

 

The 2nd and 3rd hop are both ISP hops. Just to be sure i also made a policy from trust to untrust to allow ping, but this didn't help. Anyone know why this is ?

 

Thanks Stan

Trusted Contributor
c0d3r
Posts: 59
Registered: ‎12-06-2008
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

what does a debug flow basic say ?

 

 

---------------------------------------------
http://www.corelan.be:8800
---------------------------------------------
*** Don't forget to hit the Kudos button if my answer was helpful ***
Contributor
Stan-Gobien
Posts: 44
Registered: ‎01-15-2009
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)


c0d3r wrote:

what does a debug flow basic say ?

 

 


ns25-> debug flow basic
debug flow basic

 

no further output ?

 

Do i have to do something else, i'm pretty new to CLI on a netscreen.

Super Contributor
Nadia
Posts: 94
Registered: ‎11-06-2007
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

You need to do the following:

clear db

debug flow basic

-- start the traffic in question and wait 20 seconds

get db str

 

Look at the output to determine if the traffic is dropped by the firewall and why.

 

Thanks,

Nadia

Trusted Contributor
Gavrilo
Posts: 279
Registered: ‎07-14-2008
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

Nadia why would traffic be dropped at the Firewall? 

Stan is getting responses from the ISP routers

 

I suspect this is a security measure as I don't think you want your Firewall to respond with it's IP address if somone is intent on formulating an attack.

 

Gavrilo

Trusted Contributor
c0d3r
Posts: 59
Registered: ‎12-06-2008
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

traceroute under windows uses ICMP echo requests - so if the firewall allows ping it should respond to the traceroute attempt... but apparently it doesn't (unless a UDP or TCP traceroute was performed - Linux)

 

(Gavrilo, I agree - normally a firewall should not expose it's IP easily, however the screenOS based devices can easily be detected when doing tcp traceroutes thru the firewall (for example to hosts that are in a DMZ) - so it does not do a very good job at hiding itself)

 

Anyways : the debug output should explain why the traceroute does not respond

 

 

---------------------------------------------
http://www.corelan.be:8800
---------------------------------------------
*** Don't forget to hit the Kudos button if my answer was helpful ***
Trusted Contributor
Gavrilo
Posts: 279
Registered: ‎07-14-2008
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

Thanks for clearing it up

 

Gavrilo

Contributor
Stan-Gobien
Posts: 44
Registered: ‎01-15-2009
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

Ok i got a really huge text file with the output of the db str command (the firewall is heavily in use).

 

For which keywords can i do a search to see the relevant parts ?

Distinguished Expert
muttbarker
Posts: 2,352
Registered: ‎01-29-2008
0

Re: Netscreen 25 - Shows as * on 1st hop in trace route (altough ping works)

Prior to doing a debug capture you can set "flow filters" to limit what is captured. Use the following commands:

 

get ff (shows you filters that have been defined)

set ff src-ip x.x.x.x

set ff dst-ip x.x.x.x 

unset ff id# (use to remove previously defined filters - get the ID # from the get ff command)

 

and of course "cl db" to erase the debug buffer.

Kevin Barker
JNCIP-SEC
JNCIS-ENT, FWV, SSL, WLAN
JNCIA-ER, EX, IDP, UAC, WX
Juniper Networks Certified Instructor
Juniper Networks Ambassador

Juniper Elite Reseller
J-Partner Service Specialist - Implementation

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.