Security

 View Only

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.  Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500

    Posted 02-03-2022 10:44
      |   view attached

    Dear team,

    I am struggling for days and need help to build a working Routed-based site-to-site VPN between two SRX: one SXR300 behind a DSL modem (NAT) and a SRX1500 cluster, with public IP.

    The overall schema is:

    CLIENTS (10.80.4.1/24)----SRX300 (192.168.113.2)----(192.168.113.1) Huawei DSL Modem (99.99.99.99)----Internet----(100.100.100.100) SRX1500 Cluster (DC)

    (on DSL modem, ports 500 and 4500 are forwarded to SRX300)

     

    On branch SRX300 phase I appears UP, but the Index is incrementing each minute, so is not fully established; IPSec tunnel down reason – "IKE exchange is in progress currently"
    On DC SRX1500: either no IKE output, either cookie "0000…". See below:

    SRX300:

    nnn@ilm-srx> show security ike security-associations

    Index   State  Initiator cookie  Responder cookie  Mode           Remote Address

    5567340 UP     775e2692e4c2a0f5  eb0a175c93036b6f  Main           100.100.100.100

     

          ... after 1 minute:

     

    nnn@ilm-srx> show security ike security-associations

    Index   State  Initiator cookie  Responder cookie  Mode           Remote Address

    5567341 UP     18066bed112b67b2  6862cab14ab2f4df  Main           100.100.100.100

     

    nnn@ilm-srx> show security ipsec inactive-tunnels

      Total inactive tunnels: 1

      Total inactive tunnels with establish immediately: 1

      ID           Port   Gateway          Pending SAs   Tunnel Down Reason

      131075       500    100.100.100.100    1             IKE exchange is in progress currently

     

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

     

    SRX1500:

    aram@csd-fw03> show security ike security-associations

    node0:

    --------------------------------------------------------------------------

    Index   State  Initiator cookie  Responder cookie  Mode           Remote Address

    1682860 DOWN   74b43747b349fbe2  0000000000000000  Main           99.99.99.99

     

    aram@csd-fw03> show security ipsec inactive-tunnels

    node0:

    --------------------------------------------------------------------------

      Total inactive tunnels: 1

      Total inactive tunnels with establish immediately: 1

      ID           Port   Gateway          Pending SAs   Tunnel Down Reason

      131075       500    99.99.99.99       1             No response from peer. Negotiation failed

     

          ... or:

     

    aram@csd-fw03> show security ike security-associations

    node0:

    --------------------------------------------------------------------------

     

    aram@csd-fw03> show security ipsec inactive-tunnels

    node0:

    --------------------------------------------------------------------------

      Total inactive tunnels: 1

      Total inactive tunnels with establish immediately: 1

      ID           Port   Gateway          Pending SAs   Tunnel Down Reason

      131075       500    99.99.99.99       1             IKE exchange is in progress currently

    Configs (relevant parts) are here:


    Branch SRX300:

    set interfaces st0 unit 2 family inet

    set security zones security-zone vpn interfaces st0.2

    set routing-options static route 10.99.10.0/24 next-hop st0.2

    set security ike traceoptions file aram_kmd_nnn
    set security ike traceoptions flag all

    set security ike proposal ph2 authentication-method pre-shared-keys
    set security ike proposal ph2 dh-group group14
    set security ike proposal ph2 authentication-algorithm sha-256
    set security ike proposal ph2 encryption-algorithm aes-256-cbc
    set security ike proposal ph2 lifetime-seconds 3600
    set security ike policy ilm_csd mode main
    set security ike policy ilm_csd proposals ph2
    set security ike policy ilm_csd pre-shared-key ascii-text "xxx"
    set security ike gateway ilm_csd ike-policy ilm_csd
    set security ike gateway ilm_csd address 100.100.100.100
    set security ike gateway ilm_csd dead-peer-detection probe-idle-tunnel
    set security ike gateway ilm_csd local-identity inet 192.168.113.2
    set security ike gateway ilm_csd external-interface ge-0/0/0.0

    set security ipsec proposal ph2 protocol esp
    set security ipsec proposal ph2 authentication-algorithm hmac-sha-256-128
    set security ipsec proposal ph2 encryption-algorithm aes-256-cbc
    set security ipsec proposal ph2 lifetime-seconds 13000
    set security ipsec policy ipsec_vpn_phaseII perfect-forward-secrecy keys group14
    set security ipsec policy ipsec_vpn_phaseII proposals ph2
    set security ipsec vpn ilm_csd bind-interface st0.2
    set security ipsec vpn ilm_csd ike gateway ilm_csd
    set security ipsec vpn ilm_csd ike ipsec-policy ipsec_vpn_phaseII
    set security ipsec vpn ilm_csd establish-tunnels immediately

     - security policies are also in place to allow traffic from vpn zone to internal (trust), but these are clearly not the reason of VPN Phase I issues

     

    DC SRX1500:

    set interfaces lo0 unit 0 family inet address 100.100.100.100/32
    set interfaces st0 unit 2 family inet

    set security zones security-zone vpn interfaces st0.2

    set routing-instances VR-MAIN interface lo0.0
    set routing-instances VR-MAIN interface st0.2
    set routing-instances VR-MAIN routing-options static route 10.80.4.0/24 next-hop st0.2

    set security ike traceoptions file aram_kmd_csd
    set security ike traceoptions flag all

    set security ike proposal csd_ilm authentication-method pre-shared-keys
    set security ike proposal csd_ilm dh-group group14
    set security ike proposal csd_ilm authentication-algorithm sha-256
    set security ike proposal csd_ilm encryption-algorithm aes-256-cbc
    set security ike proposal csd_ilm lifetime-seconds 3600
    set security ike policy csd_ilm mode main
    set security ike policy csd_ilm proposals csd_ilm
    set security ike policy csd_ilm pre-shared-key ascii-text "xxx"
    set security ike gateway csd_ilm ike-policy csd_ilm
    set security ike gateway csd_ilm address 99.99.99.99
    set security ike gateway csd_ilm dead-peer-detection probe-idle-tunnel
    set security ike gateway csd_ilm remote-identity inet 192.168.113.2
    set security ike gateway csd_ilm external-interface lo0.0

    set security ipsec proposal csd_ilm protocol esp
    set security ipsec proposal csd_ilm authentication-algorithm hmac-sha-256-128
    set security ipsec proposal csd_ilm encryption-algorithm aes-256-cbc
    set security ipsec proposal csd_ilm lifetime-seconds 13000
    set security ipsec policy csd_ilm perfect-forward-secrecy keys group14
    set security ipsec policy csd_ilm proposals csd_ilm
    set security ipsec vpn csd_ilm bind-interface st0.2
    set security ipsec vpn csd_ilm ike gateway csd_ilm
    set security ipsec vpn csd_ilm ike ipsec-policy csd_ilm
    set security ipsec vpn csd_ilm establish-tunnels immediately

     

    - security policies are also in place to allow traffic from vpn zone to internal (trust), but these are clearly not the reason of VPN Phase I issues

    - lo0 is part of the correct redundancy group and is up:

    Redundant-ethernet Information:
       Name         Status      Redundancy-group
       reth0        Up          1
       reth1        Up          2

    Redundant-pseudo-interface Information:
       Name         Status      Redundancy-group
       lo0          Up          0

    For obvious reasons I replaced real public IP addresses with 99.99.99.99, respectively 100.100.100.100

    I activated traceoptions plus debug level 15 for this tunnel and I gathered the outputs in the attached archive (vpn_aram.zip), containing two files: "4.1aram_kmd_csd.log" and "4.2aram_kmd_nnn.log".

    I am trying to figure out what is blocking the functionality of this tunnel; note that another VPN from branch with SRX300 with public IP towards the same SRX1500 worked like a charm …

    Please help me with some idea – what did I miss or what can be changed to try to make it work; it drove me crazy these days ...

    If needed, I can provide of course, more info.

    Thank a lot,

    Aram

    ------------------------------
    ARAM HAZARIAN
    ------------------------------

    Attachment(s)

    zip
    vpn_aram.zip   7 KB 1 version


  • 2.  RE: Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500

    Posted 02-06-2022 20:23
    Since one side is behind a nat device you will need to enable nat traversal as part of the vpn configuration.

    https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-route-based-and-policy-based-vpns-with-nat-t.html

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 3.  RE: Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500

    Posted 02-07-2022 11:32

    Hi Steve,

    First, thank you for your time and for your directions.

    I followed the instructions within "Configuring a Route-Based VPN with Only the Responder Behind a NAT Device" example, but with no success.

    Basically, I changed as follows:

    On DC SRX1500 Cluster:

    1. At IKE gateway level: removed peer address IP 99.99.99.99 (which is the external interface of Huawei modem) and replaced it with the "external" address of the SRX300 – 192.168.113.2.
    2. Added a static route towards 192.168.113.2/32 next-hop 99.99.99.99
    3. Used local-id and remote-id user-at-hostname

    On Branch SRX300 (behind NAT):

    1. Just used local-id and remote-id user-at-hostname (of course, vice-versa related to HQ); the rest was not necessary to be changed

     

    The tunnel is still not up. At branch, the IKE shows UP, but the index is incrementing every minute. Of course, Phase II is not established.

    On both sides "show security ike security-associations" shows either nothing on this tunnel, either it shows it DOWN and – very odd – both are trying to use port 500 (not 4500 !) and both are trying to be Initiator…

    Output from branch:

    > show security ike security-associations index 5573412 detail
    IKE peer 100.100.100.100, Index 5573412, Gateway Name: ilm_csd

      Role: Initiator, State: DOWN
    Initiator cookie: d80d88092e97ab8e, Responder cookie: 0000000000000000
    Exchange type: Main, Authentication method: Pre-shared-keys
    Local: 192.168.113.2:500, Remote: 100.100.100.100:500
    Reauth Lifetime: Disabled
    IKE Fragmentation: Disabled, Size: 0
    Remote Access Client Info: Unknown Client
    AAA assigned IP: 0.0.0.0
    Algorithms:
      Authentication        : (null)
      Diffie-Hellman group  : unknown
    Traffic statistics:
      Input  bytes  :                    0
      Output bytes  :                  648
      Input  packets:                    0
      Output packets:                    2
      Input  fragmentated packets:       0
      Output fragmentated packets:       0
    IPSec security associations: 0 created, 0 deleted
    Phase 2 negotiations in progress: 0

     

    Output from DC:

    > show security ike security-associations index 1694745 detail
    node0:
    --------------------------------------------------------------------------
    IKE peer 192.168.113.2, Index 1694745, Gateway Name: csd_ilm
    Role: Initiator, State: DOWN

      Initiator cookie: 7d20ee13ffb62216, Responder cookie: 0000000000000000
    Exchange type: Main, Authentication method: Pre-shared-keys
    Local: 100.100.100.100:500, Remote: 192.168.113.2:500
    Reauth Lifetime: Disabled
    IKE Fragmentation: Disabled, Size: 0
    Remote Access Client Info: Unknown Client
    AAA assigned IP: 0.0.0.0
    Algorithms:
      Authentication        : (null)
      Diffie-Hellman group  : unknown
    Traffic statistics:
      Input  bytes  :                    0
      Output bytes  :                  648
      Input  packets:                    0
      Output packets:                    2
      Input  fragmentated packets:       0
      Output fragmentated packets:       0
    IPSec security associations: 0 created, 0 deleted
    Phase 2 negotiations in progress: 0

     

    I think the main issue relays on the SRX1500 cluster somehow … My reason when asserting this is that the branch SRX is "tunneling" fine and stable with the Home location of mine (where using a standalone SRX300, no NAT, but also no cluster. Therefore, I used same setup between this branch and the DC, with no success until now.

    You can find attached a quick schema for both tunnels coming from that branch (working one with Home, and DOWN one, with DC). Please note that I have also an UP and stable tunnel from Home to DC. I attached the relevant parts of both configs as well (related to this tunnel only); if more is needed, I would gladly provide, for sure; I didn't want to flood you from the beginning …

    If you have some more time to analyze more on my case, I would be very grateful. I don't have other ideas and is odd that from same location I have a tunnel working and another not …

    Thanks,

    Aram



    ------------------------------
    ARAM HAZARIAN
    ------------------------------

    Attachment(s)



  • 4.  RE: Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500

    Posted 02-07-2022 14:11

    Hi Steve,

    Following the directions within the guide you pointed me to, it seems the speed highly affected my results.

    I replaced the sample IPs with my own ones and all ended using a private IP as gateway for the firewall at the branch site – of course, nothing could work like that …

    I optimized the configuration also adding the statement "no-nat-traversal" and everything started to work !! The tunnel is up and stable and clients on both sides can reach each other !

    Of course I cannot explain myself the entire mechanism and I'm not even sure if this result is reliable. Here are the relevant parts of the configurations:

     

    Branch:

    > show configuration security ike gateway ilm_csd
    ike-policy ilm_csd;
    address 100.100.100.100;
    no-nat-traversal;
    local-identity inet 99.99.99.99;
    external-interface ge-0/0/0.0;

     

    DC:

    > show configuration security ike gateway csd_ilm
    ike-policy csd_ilm;
    address 99.99.99.99;
    no-nat-traversal;
    external-interface lo0.0;

     

    The strange thing is that – after an hour and a half – the clients can still communicate with each other (great! ) but … the output of "show security ike security-associations" shows NOTHING

    However, on DC …

    > show security ip security-associations

    node0:
    --------------------------------------------------------------------------
    Total active tunnels: 2     Total Ipsec sas: 2

      ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway

      <131073 ESP:aes-cbc-256/sha256 265e5a1a 2712/ unlim - root 500 88.88.88.88
    >131073 ESP:aes-cbc-256/sha256 afb8f67e 2712/ unlim - root 500 88.88.88.88

      <131075 ESP:aes-cbc-256/sha256 d54ba50c 4921/ unlim - root 500 99.99.99.99
    >131075 ESP:aes-cbc-256/sha256 72d82002 4921/ unlim - root 500 99.99.99.99

    Aand similar output is on Branch...

    Although I am happy that somehow, I managed to make it work, I am not entirely pleased of this behavior …

    Please don't be mad on me 😊 and please advise me further.

    Thanks,

    Aram



    ------------------------------
    ARAM HAZARIAN
    ------------------------------



  • 5.  RE: Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500

    Posted 02-08-2022 05:41
    Thanks for the update, glad you got this working.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 6.  RE: Site-to-site VPN between branch NAT SRX300 and DC Public IP SRX1500