[j-nsp] I've got some bone head problem on an srx...but I don't see it.

[Andrew Jones]

Turn on some flow traceoptions and look at what source address the 
packets contain... it sounds like the srx might be picking an 
inappropriate source address, and finding out what that address is will 
aid troubleshooting.

On 12.06.2013 12:12, Morgan McLean wrote:
> --- JUNOS 10.4R7.5 built 2011-09-08 07:12:35 UTC
> {primary:node0}
> mmclean at srxhost> show route 4.2.2.2
>
> inet.0: 248 destinations, 251 routes (244 active, 4 holddown, 0 
> hidden)
> + = Active Route, - = Last Active, * = Both
>
> 0.0.0.0/0          *[Static/5] 2w5d 01:07:06
>                     > to x.x.x.237 via ge-2/0/23.0
>
> {primary:node0}
> mmclean at srxhost > ping 4.2.2.2
> PING 4.2.2.2 (4.2.2.2): 56 data bytes
> ^C
> --- 4.2.2.2 ping statistics ---
> 1 packets transmitted, 0 packets received, 100% packet loss
>
> {primary:node0}
> mmclean at srxhost> ping 4.2.2.2 source x.x.x.238
> PING 4.2.2.2 (4.2.2.2): 56 data bytes
> 64 bytes from 4.2.2.2: icmp_seq=0 ttl=59 time=12.020 ms
> ^C
> --- 4.2.2.2 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 12.020/12.020/12.020/0.000 ms
>
> {primary:node0}
>
>
> On Tue, Jun 11, 2013 at 7:09 PM, Morgan McLean <wrx230 at gmail.com> 
> wrote:
>
>> I've gotten a couple replies off list. There is an any policy from 
>> trust
>> to untrust, and the untrust zone does have host inbound traffic ping
>> enabled. I think the ping not responding is a byproduct of whatever 
>> is
>> going on, though.
>>
>> Morgan
>>
>>
>> On Tue, Jun 11, 2013 at 6:29 PM, Morgan McLean <wrx230 at gmail.com> 
>> wrote:
>>
>>> I have an SRX cluster at an office with a single connection to the 
>>> web at
>>> the moment. It has a couple ipsec connections out to our 
>>> datacenters, and a
>>> couple local subnets hanging on RETH interfaces.
>>>
>>> For the life of me, I can't figure out why I'm unable to ping out 
>>> from
>>> this system. Even if I try to ping the point to point between us 
>>> and
>>> Verizon, a direct route, it won't work unless I specify the source 
>>> address
>>> as our local interface address.
>>>
>>> Outbound nat from clients behind the SRX works fine. The loopback 
>>> is in
>>> trust, and I have a couple zones + trust with a source nat rule 
>>> using the
>>> verizon interface IP as the egress point. Destination nat rules 
>>> work.
>>>
>>> So everything seems to work...except from the SRX. As a result, we 
>>> cannot
>>> ping the SRX remotely...but again IPSEC works.
>>>
>>> Any great tips? None of our other SRX's behave like this...and its
>>> driving me nuts!
>>>
>>>
>>> --
>>> Thanks,
>>> Morgan
>>>
>>
>>
>>
>> --
>> Thanks,
>> Morgan
>>