SRX Services Gateway
Reply
Contributor
IanK
Posts: 77
Registered: ‎10-09-2008
0

ICMP outbound problem

I have a SRX running 10.2R2.11

I am trying to verify that I have icmp reachability of a VPN end point( and other devices)  that I can reach from anywhere on the internet ,

SRX---Untust---Internet---hostx.x.x.x---

there is a 0/0 routing out a defined Untrust zone
host-inbound-traffic system-services all is configured on the Untrust zone and untrust interface
host-inbound-traffic protocols all is configured on the Untrust zone and untrust interface

a flow trace & flow session indicate that there is bi directional communication and that nothing is getting dropped.

NOTE: I am trying to ping from the firewall , and I don't want the firewall to be visible on the internet.

What am I missing here ?

Distinguished Expert
keithr
Posts: 979
Registered: ‎09-10-2009
0

Re: ICMP outbound problem

Seeing your configuration would help.

 

Your SRX probably has multiple IP addresses on different interfaces.  Some of those probably aren't routable on the Internet.  Issue the ping from a source address on the SRX that you know is routable back from your remote device:

 

thedude@fw1> ping 1.1.1.1 source x.y.z.q verbose

 

If you don't specify the source address, you will see which address the ping is originating from.  I would suspect it's probably a private / internal IP address and there's no route back to it from your remote host.

 

Also check your security policies... sounds like you may have already run traceoptions.  What traces did you do, can you post the output?  You may have simply confirmed that the ICMP packets are leaving, but you might not be seeing them come back.

 

With a little more information we can help better.

 

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Contributor
IanK
Posts: 77
Registered: ‎10-09-2008
0

Re: ICMP outbound problem

 

Hi , the traces were flow traces , and i could see the the packed create a bi-directional sesion

 

 

{primary:node0}
root@srx> ping 212.58.246.95 source x.x.x.x count 100 rapid 
PING 212.58.246.95 (212.58.246.95): 56 data bytes
................................................................................^C
--- 212.58.246.95 ping statistics ---

Session ID: 160200740, Policy name: self-traffic-policy/1, State: Active, Timeout: 4, Valid
  In: x.x.x.x/7 --> 212.58.246.95/45078;icmp, If: .local..0, Pkts: 1, Bytes: 84
  Out: 212.58.246.95/45078 --> x.x.x.x/7;icmp, If: reth0.100, Pkts: 1, Bytes: 84

when i did the trace i could see the srx was using the untrust ip adress anyway , so i know its using the correct interface.

 

 

anything else ?

Distinguished Expert
keithr
Posts: 979
Registered: ‎09-10-2009
0

Re: ICMP outbound problem

You're seeing the SRX create the session, but we still have no confirmation whether packets are actually coming back to the SRX or not.

 

If you could post your configuration, that would really help narrow down possible causes much faster, and we can suggest things to try based on what we see in your config.

 

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Contributor
IanK
Posts: 77
Registered: ‎10-09-2008
0

Re: ICMP outbound problem

1. The session log extract above  shows a Bi-directional session established , if it was only one way communication you would not see it in the session log.

 

2. Additionally I executed a flow trace on any ICMP packets sourced or destined to the external IP that I am trying to ping , and I can confirm that

a) outbound packet from Junos-self  to the Untrust Zone via the correct Untrust interface destined to external IP

b) Inbound packet from Untrust zone to Junos self  ( note packets are NOT dropped )

 

3. the config of this device is circa 130K lines ... so uploading it is not an option

 

Super Contributor
colemtb
Posts: 313
Registered: ‎09-30-2009
0

Re: ICMP outbound problem

Is your source interface in a different routing instance?  If so, that would be a problem, host-inbound-STUFF doesn't apply to interfaces not in inet.0. 

 

Just a guess.

 

Thanks!

Contributor
IanK
Posts: 77
Registered: ‎10-09-2008
0

Re: ICMP outbound problem

Hi  Source interface is in inet.0

Distinguished Expert
keithr
Posts: 979
Registered: ‎09-10-2009
0

Re: ICMP outbound problem

 


IanK wrote:

1. The session log extract above  shows a Bi-directional session established , if it was only one way communication you would not see it in the session log.


When you initiate the ping, the device creates the session in the session table as a bidirectional session so that the return packet is allowed back in.  This is normal behavior.  However, the existence of the bidirectional session entry does not mean that a packet is actually coming into the device.


IanK wrote:

2. Additionally I executed a flow trace on any ICMP packets sourced or destined to the external IP that I am trying to ping , and I can confirm that

a) outbound packet from Junos-self  to the Untrust Zone via the correct Untrust interface destined to external IP

b) Inbound packet from Untrust zone to Junos self  ( note packets are NOT dropped )


OK, could you post the output from that trace?  Here is how I configured a test trace on one of my devices:

 

security {
  flow {
    traceoptions {
      file pingtrace size 2m files 20;
      flag basic-datapath;
      packet-filter f1 {
        protocol icmp;
        source-prefix 10.1.1.1/32;
      }
      packet-filter f2 {
        protocol icmp;
        destination-prefix 10.1.1.1/32;
      }
    }
  }
}

 

The output that is logged in your tracefile may help indicate what's going on.

 

You can also try a packet capture on the interface that connects to your upstream device.


IanK wrote:

3. the config of this device is circa 130K lines ... so uploading it is not an option 


You can sanitize the configuration to remove passwords, IP addresses, etc. that you may find sensitive and post the rest as an attachment here.  We can find the relevant parts.

 

It's really difficult to help troubleshoot a problem when we don't have information to reference.  We're just trying to help as best as we can.

 

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.