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 <[email protected]> wrote: > > On 12/06/2013, at 11:29 AM, Morgan McLean <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
