I rolled back and ran a ping to a host out on the net. Heres the trace...is the fact that its coming from junos-self screwing things up?
Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: chose interface .local..0 as incoming nat if. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_rule_dst_xlate: packet 192.168.29.11->192.81.130.21 nsp2 0.0.0.0->192.81.130.21. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.29.11, x_dst_ip 192.81.130.21, in ifp .local..0, out ifp N/A sp 8, dp 207, ip_proto 1, tos 0 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:Doing DESTINATION addr route-lookup Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: routed (x_dst_ip 192.81.130.21) from junos-self (.local..0 in 0) to ge-2/0/23.0, Next-hop: 157.130.198.237 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: policy search from zone junos-self-> zone untrust (0x0,0x800cf,0xcf) Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: app 0, timeout 60s, curr ageout 60s Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: dip id = 0/0, 192.168.29.11/8-> 192.168.29.11/8 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: choose interface ge-2/0/23.0 as outgoing phy if Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:is_loop_pak: No loop: on ifp: ge-2/0/23.0, addr: 192.81.130.21, rtt_idx:0 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: check nsrp pak fwd: in_tun=0x0, VSD 0 for out ifp ge-2/0/23.0 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: vsd 0 is active Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:jsf sess interest check. regd plugins 13 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: Allocating plugin info block for 12 plugin(s) from OL Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 1, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 2, svc_req 0x2. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 3, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 5, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:+++++++++++jsf_test_plugin_data_evh: 3 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 6, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 7, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 8, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 10, svc_req 0x0. rc 4 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:-jsf int check: plugin id 11, svc_req 0x0. rc 2 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: No JSF plugins enabled for session Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: Releasing plugin info block for 12 plugin(s) to OL Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_service_lookup(): natp(0x58c92bc8): app_id, 0(0). Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: service lookup identified service 0. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: flow_first_final_check: in <.local..0>, out <ge-2/0/23.0> Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:construct v4 vector for nsp2 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: existing vector list 220-4942b678. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: Session (id:104814) created for first pak 220 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: flow_first_install_session======> 0x58c92bc8 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: nsp 0x58c92bc8, nsp2 0x58c92c2c Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: make_nsp_ready_no_resolve() Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: route lookup: dest-ip 192.168.29.11 orig ifp .local..0 output_ifp .local..0 orig-zone 2 out-zone 2 vsd 0 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: route to 192.168.29.11 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:Installing c2s NP session wing Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:Installing s2c NP session wing Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: flow got session. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: flow session id 104814 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: vector bits 0x220 vector 0x4942b678 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: vsd 0 is active Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:mbuf 0x44f31b80, exit nh 0x150010 Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_process_pkt_exception: Freeing lpak 51990930 associated with mbuf 0x44f31b80 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
