SRX

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-19-2016 03:42

    Hi

     

    I've built a Policy based IPSec VPN and having issue communicating from SRX box to far end LAN- 192.168.5.0/24

     

    The VPN Tunnel is UP and LAN to LAN comminication is working without any problem. However I'm unable to access / ping any devices in 192.168.5.0/24 from SRX Box. Need your valuable suggestion in resolving the same.

     

    Setup:

    LAN_A (192.168.41.0/24) ----- SRX650(local) ---- VPN ---- Checkpoint R77.20(remote) ------ LAN_B (192.168.5.0/24)

     

    Configuration Sniplets:

     

    Routing:

     

    root@Site_A> show configuration routing-options | display set
    set routing-options static route 0.0.0.0/0 next-hop X.X.X.X

    =============================================================================================

    NAT Rule :

     

    source NAT rule: LAN_A-to-LAN_B Rule-set: DMZ-to-untrust
    Rule-Id : 3
    Rule position : 3
    From zone : DMZ
    To zone : untrust
    Match
    Source addresses : 192.168.41.0 - 192.168.41.255
    Destination addresses : 192.168.5.0 - 192.168.5.255
    Destination port : 0 - 0
    Action : off
    Persistent NAT type : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout : 0
    Max session number : 0
    Translation hits : 21354216

    =============================================================================================

    Trace Config:

     

    root@Site_A# show security flow | display set
    set security flow traceoptions file syslog-cap
    set security flow traceoptions file size 1m
    set security flow traceoptions flag all
    set security flow traceoptions packet-filter src source-prefix 192.168.41.1/32
    set security flow traceoptions packet-filter src destination-prefix 192.168.5.102/32
    set security flow allow-dns-reply
    set security flow tcp-mss ipsec-vpn mss 1350

    =============================================================================================

    Policy Config:

     

    From zone: DMZ, To zone: untrust
    Policy: LAN_A-to-LAN_B, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
    Source addresses: LAN_A
    Destination addresses: LAN_B
    Applications: any
    Action: permit, tunnel, log

    From zone: untrust, To zone: DMZ
    Policy: LAN_B-to-LAN_A, State: enabled, Index: 11, Scope Policy: 0, Sequence number: 1
    Source addresses: LAN_B
    Destination addresses: LAN_A
    Applications: any
    Action: permit, tunnel, log

    =============================================================================================

    root@Site_A> show configuration security zones security-zone untrust | display set | match host
    set security zones security-zone untrust host-inbound-traffic system-services all
    set security zones security-zone untrust host-inbound-traffic protocols all
    set security zones security-zone untrust interfaces reth0.0 host-inbound-traffic system-services all
    set security zones security-zone untrust interfaces reth0.0 host-inbound-traffic protocols all

    =============================================================================================

     

    Logs :

     

    root@Site_A> show security ike sa
    node0:
    --------------------------------------------------------------------------
    Index State Initiator cookie Responder cookie Mode Remote Address
    4729448 UP 52f6610d2fa81a23 7f51ee40b344a463 Main Y.Y.Y.Y
    4729449 UP 6ad43fc840754a6e 23c7b42ed2b4355b Main Y.Y.Y.Y

    root@Site_A> show security ipsec security-associations
    node0:
    --------------------------------------------------------------------------
    Total active tunnels: 7
    ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
    ❤️ ESP:3des/sha1 ad154b5a 2502/ unlim - root 500 Y.Y.Y.Y
    >3 ESP:3des/sha1 a47eeb3b 2502/ unlim - root 500 Y.Y.Y.Y
    <4 ESP:3des/sha1 404c8063 2588/ unlim - root 500 Y.Y.Y.Y
    >4 ESP:3des/sha1 f896c87c 2588/ unlim - root 500 Y.Y.Y.Y
    <5 ESP:3des/sha1 aa5421bb 1204/ unlim - root 500 Y.Y.Y.Y
    >5 ESP:3des/sha1 d8baf58d 1204/ unlim - root 500 Y.Y.Y.Y
    <6 ESP:3des/sha1 3d040e70 1989/ unlim - root 500 Y.Y.Y.Y
    >6 ESP:3des/sha1 1161b58e 1989/ unlim - root 500 Y.Y.Y.Y
    <7 ESP:3des/sha1 7e2d4662 2601/ unlim - root 500 Y.Y.Y.Y
    >7 ESP:3des/sha1 c5dac937 2601/ unlim - root 500 Y.Y.Y.Y
    <16 ESP:3des/sha1 924a4007 2057/ unlim - root 500 Y.Y.Y.Y
    >16 ESP:3des/sha1 6fea302 2057/ unlim - root 500 Y.Y.Y.Y

    =============================================================================================

    root@Site_A> show security flow session destination-prefix 192.168.5.102 extensive
    node0:
    --------------------------------------------------------------------------

    Session ID: 425524, Status: Normal, State: Active
    Flag: 0x8000040
    Policy name: self-traffic-policy/1
    Source NAT pool: Null, Application: junos-syslog/23
    Dynamic application: junos:UNKNOWN,
    Maximum timeout: 60, Current timeout: 60
    Session State: Valid
    Start time: 23048601, Duration: 44442
    In: 192.168.41.1/514 --> 192.168.5.102/514;udp,
    Interface: .local..0,
    Session token: 0x2, Flag: 0x0x31
    Route: 0xfffb0006, Gateway: 192.168.41.1, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 405408, Bytes: 106514307
    Out: 192.168.5.102/514 --> 192.168.41.1/514;udp,
    Interface: reth0.0,
    Session token: 0x6, Flag: 0x0x20
    Route: 0x45abc1, Gateway: X.X.X.X, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 0, Bytes: 0
    Total sessions: 1

    =============================================================================================

    Trace Log:

     

     

    root@Site_A> show log syslog-cap
    Feb 18 00:57:56 00:57:56.427765:CID-1:RT:flow_process_pkt_exception: setting rtt in lpak to 70370958
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT:inq_type 0x5
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT:Using vr id from pfe_tag with value= 0
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT:Changing lpak->in_ifp from:.local..0 -> to:.local..0
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT: Over-riding lpak->vsys with 0
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT: find flow: table 0x53a20868, hash 48854(0xffff), sa 192.168.41.1, da 192.168.5.102, sp 514, dp 514, proto 17, tok 2
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT: flow got session.
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT: flow fast tcp/udp session id 508912
    Feb 18 00:57:56 00:57:56.427773:CID-1:RT: vector bits 0x20 vector 0x490c66d0
    Feb 18 00:57:56 00:57:56.427865:CID-1:RT: vsd 1 is active
    Feb 18 00:57:56 00:57:56.427865:CID-1:RT:mbuf 0x44e85980, exit nh 0x4163c1
    Feb 18 00:57:56 00:57:56.427865:CID-1:RT:flow_process_pkt_exception: Freeing lpak 3f7e78e8 associated with mbuf 0x44e85980
    Feb 18 00:57:56 00:57:56.427865:CID-1:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 0
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 1
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 2
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:session_ha_copy_session_info_to_msg: appid not valid plugin
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:Create sess msg: flag=40000040 IN nsp:
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT: c0a805c9/35383->c0a82919/135,6, vsys:0, if_info: 66,vsi:,tun = 0x20000003, sync_id=0x100637d0, l2_zone_cookie=0
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT: OUT nsp:
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT: c0a82919/135->c0a805c9/35383,6, vsys:0, if_info: 67,vsi:,tun = 0x0, sync_id=0x100637d0, l2_zone_cookie=0
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:IN wsf: 0, OUT wsf: 0,
    Feb 18 00:57:56 00:57:55.1402737:CID-1:RT:sm_app_flag: 0,
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 0
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 1
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:session_ha_copy_session_info_to_msg: Convert app_cookie handle 0 to id 0 for module 2
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:session_ha_copy_session_info_to_msg: appid not valid plugin
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:Create sess msg: flag= 40 IN nsp:
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT: c0a8292c/37901->c0a80516/53,17, vsys:0, if_info: 67,vsi:,tun = 0x0, sync_id=0x100637ce, l2_zone_cookie=0
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT: OUT nsp:
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT: c0a80516/53->c0a8292c/37901,17, vsys:0, if_info: 66,vsi:,tun = 0x20000003, sync_id=0x100637ce, l2_zone_cookie=0
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:IN wsf: 0, OUT wsf: 0,
    Feb 18 00:57:56 00:57:55.1314373:CID-1:RT:sm_app_flag: 0,
    Feb 18 00:57:56 00:57:55.1329923:CID-1:RT: <192.168.41.1/514->192.168.5.102/514;17> matched filter src:
    Feb 18 00:57:56 00:57:55.1329923:CID-1:RT: packet [249] ipid = 64761, @44e891ce
    Feb 18 00:57:56 00:57:55.1329962:CID-1:RT:---- flow_process_pkt: (thd 11): flow_ctxt type 0, common flag 0x0, mbuf 0x44e85980, rtbl_idx = 0
    Feb 18 00:57:56 00:57:55.1329962:CID-1:RT:flow process pak, mbuf 44e85980, ifl 0, ctxt_type 0 inq type 5
    Feb 18 00:57:56 00:57:55.1329962:CID-1:RT: in_ifp <junos-self:.local..0>
    Feb 18 00:57:56 00:57:55.1329962:CID-1:RT:flow_process_pkt_exception: setting rtt in lpak to 70370958
    Feb 18 00:57:56 00:57:55.1330015:CID-1:RT:inq_type 0x5
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT:Using vr id from pfe_tag with value= 0
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT:Changing lpak->in_ifp from:.local..0 -> to:.local..0
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: Over-riding lpak->vsys with 0
    Feb18 00:57:56 00:57:55.1330022:CID-1:RT: find flow: table 0x53a20868, hash 48854(0xffff), sa 192.168.41.1, da 192.168.5.102, sp 514, dp 514, proto 17, tok 2
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: flow got session.
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: flow fast tcp/udp session id 508912
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: vector bits 0x20 vector 0x490c66d0
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: vsd 1 is active
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT:mbuf 0x44e85980, exit nh 0x4163c1
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT:flow_process_pkt_exception: Freeing lpak 3f3e38e8 associated with mbuf 0x44e85980
    Feb 18 00:57:56 00:57:55.1330022:CID-1:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)
    Feb 18 00:57:56 00:57:55.1403239:CID-1:RT: Send Update sess msg, action=1, length=2, Session id=0x7000065b96. key:
    Feb 18 00:57:56 00:57:55.1403741:CID-1:RT: c0a805c9/35383->c0a82919/135,6, vsys:0, if_info: 66,vsi:,tun = 0x20000003, sync_id=0x100637d0, l2_zone_cookie=0
    Feb 18 00:57:56 00:57:55.1403741:CID-1:RT:TYPE_SESS_UPDATE_WSF msg for sess 0x7000065b96:
    Feb 18 00:57:56 00:57:55.1403741:CID-1:RT:in_nspwsf=8, out_nspwsf=8
    Feb 18 00:57:56 00:57:56.690583:CID-1:RT: <192.168.41.1/514->192.168.5.102/514;17> matched filter src:
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: packet [285] ipid = 64766, @44e891ce
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: ---- flow_process_pkt: (thd 4): flow_ctxt type 0, common flag 0x0, mbuf 0x44e85980, rtbl_idx = 0
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:flow process pak, mbuf 44e85980, ifl 0, ctxt_type 0 inq type 5
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: in_ifp <junos-self:.local..0>
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:flow_process_pkt_exception: setting rtt in lpak to 70370958
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:inq_type 0x5
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:Using vr id from pfe_tag with value= 0
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:Changing lpak->in_ifp from:.local..0 -> to:.local..0
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: Over-riding lpak->vsys with 0
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: find flow: table 0x53a20868, hash 48854(0xffff), sa 192.168.41.1, da 192.168.5.102, sp 514, dp 514, proto 17, tok 2
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: flow got session.
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: flow fast tcp/udp session id 508912
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: vector bits 0x20 vector 0x490c66d0
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: vsd 1 is active
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:mbuf 0x44e85980, exit nh 0x4163c1
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT:flow_process_pkt_exception: Freeing lpak 3faea8e8 associated with mbuf 0x44e85980
    Feb 18 00:57:56 00:57:56.690589:CID-1:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)
    Feb 18 00:57:56 00:57:56.692461:CID-1:RT: <192.168.41.1/514->192.168.5.102/514;17> matched filter src:
    Feb 18 00:57:56 00:57:56.692461:CID-1:RT: packet [259] ipid = 64771, @44e891ce
    Feb 18 00:57:56 00:57:56.692461:CID-1:RT:---- flow_process_pkt: (thd 4): flow_ctxt type 0, common flag 0x0, mbuf 0x44e85980, rtbl_idx = 0
    Feb 18 00:57:56 00:57:56.692461:CID-1:RT:flow process pak, mbuf 44e85980, ifl 0, ctxt_type 0 inq type 5
    Feb 18 00:57:56 00:57:56.692461:CID-1:RT: in_ifp <junos-self:.local..0>

    ======================================================================================================================================================================================

     

    Thanks.

     

     


    #SRX
    #vpn
    #policybasedvpn
    #IPSec
    #Juniper


  • 2.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-19-2016 12:24

    Hi ajay_kumar,

     

    What do you mean by  :

     

    "The VPN Tunnel is UP and LAN to LAN comminication is working without any problem. However I'm unable to access / ping any devices in 192.168.5.0/24 from SRX Box."

     

    Do you mean you can ping from any PC on your LAN ( 192.168.41.0/24 ) to the remote LAN 192.168.5.0/24 except from the SRX ?

     

    Your Obscufication of the IPs using the same annotation ( Y.Y.Y.Y ) makes the logs you posted almost useless, can you post the configuration please ?



  • 3.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-19-2016 23:38

     

    Hi Hisham

     

    Sorry for the confusion and what you have mentiond is correct. I can ping from any PC in 192.168.41.0/24 to any machine in 192.168.5.0/24 and vice versa, however I'm not able to do so from SRX box (with source interface 192.168.41.1) to 192.168.5.0/24 IP's.

     

    X.X.X.X - is next hop for the default route installed in SRX.

     

    Y.Y.Y.Y - is externeal IP for 192.168.5.0/24 where VPN is terminated.

     

    SRX DMZ interface config

     

    set interfaces reth1 description DMZ
    set interfaces reth1 unit 0 family inet address 192.168.41.1/24

     

    Thanks,

    Ajay



  • 4.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-20-2016 09:41

    Hi ajay_kumar,

     

     

    Can you enable packet tracing :

     

    set security flow traceoptions file DebugTraffic
    set security flow traceoptions flag basic-datapath

    set security flow traceoptions packet-filter MatchTraffic source-prefix 192.168.41.1/32 destination-prefix 192.168.5.102/32

     

    Then can you try pinging using this command :

     

    >ping interface reth1.0 192.168.5.102

     

    And provide us with the output from the log file DebugTraffic ?



  • 5.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-23-2016 02:43
      |   view attached

    Hi Hisham

     

    As requested I've run the trace and attched the output.

     

    Hello Andrew

     

    Thanks for your inputs. Can you please elaborate what you have mentioned.

     

    My inside interface (configured as DMZ Zone) is reth1.0 to where (192.168.41.0/24 ) is connected and VPN traffic is initiated from here. Outgoing interface is reth0.0 which is in Untrust Zone

     

    Thanks,

    Ajay Kumar

    Attachment(s)

    txt
    site-A_FW.txt   53 KB 1 version


  • 6.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-24-2016 22:03

     

    All Experts here, does anybody have any idea what might have gone wrong.

     

    Thanks,

    Ajay Kumar



  • 7.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 03-01-2016 03:59

    Hi,

     

    In policy based VPN proxy IDs are matched on local and remote sites. I believe you have defined correct proxy-id on both sites that is why you're able to ping from LAN to LAN. The reason why you're not able to do from the SRX is obvious, did you define any proxy-id on remote site to match the outgoing ip of srx? When you run ping from SRX it matches the policy Self-traffic-policy because traffic is originated from box itself.

     

    Another way is you try to ping using the LAN ip ( if possible) on SRX.

     

    BR,

    MYN



  • 8.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 03-01-2016 23:03

    The triggering point for the IPSec traffic is the policy "From zone: DMZ, To zone: untrust", which is the transit traffic,

     

    When you ping from SRX itself it is a self generated traffic and wont hit policy.

     

    To confirm this you can check if the policy counter is incrementing while you do the ping "show security policies hit-count".

    -IE



  • 9.  RE: SRX- 650 || Policy Based VPN || Communication Issue
    Best Answer

    Posted 03-08-2016 07:49

    All,

     

    Finallly the issue is resolved by raising this case with JTAC. The Solution is to have a Route Based VPN which worked perfectly.

     

    Engineer suggested that there is a shortcoming in Policy Based VPN's for self generated traffic in SRX boxes. He informed that he has seen similar cases related to Policy Based VPN's where traffic generated from SRX box is not passing via the Tunnel.

     

    The sad part is that Juniper doent have a KB article or any documentaion for this issue / scenario.

     

    Finally thank you all for your valuable suggestions.

     

    HTH,

    Ajay Kumar

     

     


    #SRX
    #Juniper
    #vpntunnel
    #policybasedvpn


  • 10.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 03-13-2016 22:10

     

    Yes do remember that NAT and policy Base VPn on same SRX is big NO NO!



  • 11.  RE: SRX- 650 || Policy Based VPN || Communication Issue

    Posted 02-22-2016 20:46

    I got caught with something similar and it took me ages to find the answer.

    There is a "BUG" (they say feature) in JUNOS hat reqires the VPN and the interface through which the data flows to be in the same security zone.

    I hope this helps.