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

[Morgan McLean]

The issue is I had default address selection enabled. I don't use FXP on
any of my devices, I don't believe in it. I think routed loopback is a more
sound management option in the event of a failure.

Regardless, the weird thing is the loopback was in trust zone, which is
allowed to get to untrust, is part of the source nat rule, etc. No idea why
it wasn't working. I'd forgot I enabled it, and it escaped my eyes when I
looked at the config block.

I might re-enable it and try a packet trace...which I had done before but
saw nothing. I'll report back in a few minutes.

Morgan


On Tue, Jun 11, 2013 at 9:47 PM, Ben Dale <bdale at comlinx.com.au> wrote:

>
> On 12/06/2013, at 11:29 AM, 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!
>
> Being a cluster, this isn't fxp0 interface shenanigans is it?  Do you have
> the managemen function zone applied to fxp0?
>
> Ben




-- 
Thanks,
Morgan