Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Unable to transfer traffic over route based ipsec vpn with established PH2

    Posted 07-26-2021 05:24

    Hi all,

    We are having a new VPN concentrator in our DC and we are trying to establish an IPSEC connection between a remote site SRX 345 and the 6Wind (linux based router) concentrator.
    The phase 2 link is online but we notice that no traffic is reaching the other side of the tunnel. 

    This is the configuration of the 6wind hardware

     pre-shared-key rw_psk
    secret <secret>ike-policy-template ike_template01
    ike-proposal 1
    enc-alg aes256-cbc
    auth-alg hmac-sha256
    dh-group modp15366ipsec-policy-template ipsec_template01
    esp-proposal 1
    enc-alg aes128-cbc
    auth-alg hmac-sha256
    dh-group modp1536vpn vpn_RW
    dynamic-svti
    svti-template SVTI_RW
    vrf vrf-RemoteSites
    ..
    ike-policy
    template ike_template01
    ..
    ipsec-policy
    template ipsec_template01
    ..
    description vpn_access_for_rw_with_subnet
    version 2
    local-address <pub ip>
    security-policy hub0
    local-ts subnet 10.10.0.0/24
    remote-ts subnet 0.0.0.0/0
    action esp
    mode tunnel
    priority 0
    ..
    security-policy hub8
    local-ts subnet 10.10.8.0/23
    remote-ts subnet 0.0.0.0/0
    action esp
    mode tunnel
    priority 0

    The security config of the SRX looks like this:

    ike {
    proposal CM_DC_IKE-PROPOSAL {
    authentication-method pre-shared-keys;
    dh-group group5;
    authentication-algorithm sha-256;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 14400;
    }
    policy CM_DC_IKE-POLICY {
    mode main;
    proposals CM_DC_IKE-PROPOSAL;
    pre-shared-key ascii-text "<secret>"; ## SECRET-DATA
    }
    gateway CM_DC_IKE-GATEWAY {
    ike-policy CM_DC_IKE-POLICY;
    address <pubip>;
    external-interface ge-0/0/0.0;
    version v2-only;
    }
    }
    ipsec {
    proposal CM_DC_IPSEC-PROPOSAL {
    protocol esp;
    authentication-algorithm hmac-sha-256-128;
    encryption-algorithm aes-128-cbc;
    lifetime-seconds 3600;
    }
    policy CM_DC_IPSEC-POLICY {
    perfect-forward-secrecy {
    keys group5;
    }
    proposals CM_DC_IPSEC-PROPOSAL;
    }
    vpn CM_DC_IPSEC-VPN {
    bind-interface st0.0;
    ike {
    gateway CM_DC_IKE-GATEWAY;
    ipsec-policy CM_DC_IPSEC-POLICY;
    }
    traffic-selector DC {
    local-ip 10.33.6.0/23;
    remote-ip 10.10.8.0/23;
    }
    inactive: traffic-selector DC2 {
    local-ip 10.33.6.0/23;
    remote-ip 10.10.0.0/24;
    }
    establish-tunnels immediately;
    }
    }
    address-book {
    global {
    address DC_CM1 10.10.0.0/24;
    address LOCAL_LMP 192.168.255.129/32;
    address RFC1918_1 10.0.0.0/8;
    address RFC1918_2 172.16.0.0/12;
    address RFC1918_3 192.168.0.0/16;
    address LOCAL_MGMT 10.33.6.0/28;
    address DC_CM2 10.10.8.0/23;
    address-set CM_DC {
    address DC_CM1;
    address DC_CM2;
    }
    address-set RFC1918 {
    address RFC1918_1;
    address RFC1918_2;
    address RFC1918_3;
    }
    }
    }
    flow {
    tcp-mss {
    ipsec-vpn {
    mss 1350;
    }
    }
    }
    nat {
    source {
    rule-set Local-To-WAN {
    from zone trust-main;
    to zone WAN;
    rule SNAT-WAN {
    match {
    destination-address 0.0.0.0/0;
    }
    then {
    source-nat {
    interface;
    }
    }
    }
    rule SNAT-RFC1918 {
    match {
    destination-address-name RFC1918;
    }
    then {
    source-nat {
    off;
    }
    }
    }
    }
    rule-set Local-To-LMP {
    from routing-instance default;
    to zone trust-main;
    rule SNAT-LMP {
    match {
    destination-address 192.168.255.129/32;
    }
    then {
    source-nat {
    interface;
    }
    }
    }
    }
    }
    destination {
    pool LMP-Nokia {
    address 192.168.255.129/32 port 443;
    }
    rule-set nat-LMP {
    from zone WAN;
    rule port-forwarding {
    match {
    destination-address 0.0.0.0/0;
    application HTTPS-DNAT;
    }
    then {
    destination-nat {
    pool {
    LMP-Nokia;
    }
    }
    }
    }
    }
    }
    }
    policies {
    from-zone trust-main to-zone IPSEC_DC {
    policy ipsec-out {
    match {
    source-address LOCAL_MGMT;
    destination-address CM_DC;
    application any;
    }
    then {
    permit;
    }
    }
    }
    from-zone IPSEC_DC to-zone trust-main {
    policy ipsec-in {
    match {
    source-address CM_DC;
    destination-address LOCAL_MGMT;
    application any;
    }
    then {
    permit;
    }
    }
    }
    from-zone trust-main to-zone WAN {
    policy any-permit {
    match {
    source-address any;
    destination-address any;
    application any;
    }
    then {
    permit;
    }
    }
    }
    from-zone WAN to-zone trust-main {
    policy LMP-DNAT {
    match {
    source-address any;
    destination-address LOCAL_LMP;
    application junos-https;
    }
    then {
    permit;
    }
    }
    }
    from-zone trust-S1 to-zone trust-S1 {
    policy any-permit {
    match {
    source-address any;
    destination-address any;
    application any;
    }
    then {
    permit;
    }
    }
    }
    from-zone trust-DNN1 to-zone trust-DNN1 {
    policy permit-any {
    match {
    source-address any;
    destination-address any;
    application any;
    }
    then {
    permit;
    }
    }
    }
    default-policy {
    deny-all;
    }
    }
    zones {
    security-zone trust-main {
    host-inbound-traffic {
    system-services {
    all;
    }
    protocols {
    all;
    }
    }
    interfaces {
    irb.310;
    ge-0/0/3.0;
    lo0.0;
    }
    }
    security-zone trust-S1 {
    host-inbound-traffic {
    system-services {
    ping;
    traceroute;
    }
    }
    interfaces {
    ge-0/0/14.320;
    ge-0/0/15.322;
    ge-0/0/11.400;
    }
    }
    security-zone trust-DNN1 {
    host-inbound-traffic {
    system-services {
    ping;
    traceroute;
    }
    }
    interfaces {
    ge-0/0/14.350;
    ge-0/0/7.0;
    }
    }
    security-zone WAN {
    host-inbound-traffic {
    system-services {
    dhcp;
    https;
    ping;
    ssh;
    ike;
    traceroute;
    }
    }
    interfaces {
    ge-0/0/0.0;
    }
    }
    security-zone IPSEC_DC {
    host-inbound-traffic {
    system-services {
    ping;
    ssh;
    traceroute;
    https;
    }
    }
    interfaces {
    st0.0;
    }
    }
    }

    both ike and ipsec are established:

    root@PR_KUL_CR01> show security ike security-associations
    Index State Initiator cookie Responder cookie Mode Remote Address
    5541995 UP b3540d6607f678f1 6969aee3246897f4 IKEv2 <pubip>

    root@PR_KUL_CR01> show security ipsec security-associations detail
    ID: 67108866 Virtual-system: root, VPN Name: CM_DC_IPSEC-VPN
    Local Gateway: <local ip>, Remote Gateway: <pubip>
    Traffic Selector Name: DC
    Local Identity: ipv4(10.33.6.0-10.33.7.255)
    Remote Identity: ipv4(10.10.8.0-10.10.9.255)
    Version: IKEv2
    DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.0
    Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29
    Multi-sa, Configured SAs# 1, Negotiated SAs#: 1
    Tunnel events:
    Mon Jul 26 2021 08:30:48: IPSec SA negotiation successfully completed (1 times)
    Mon Jul 26 2021 08:30:48: IKE SA negotiation successfully completed (5 times)
    Mon Jul 26 2021 08:30:10: User cleared IKE SA from CLI, corresponding IPSec SAs cleared (1 times)
    Mon Jul 26 2021 07:54:48: IPSec SA negotiation successfully completed (1 times)
    Mon Jul 26 2021 07:53:50: User cleared IKE SA from CLI, corresponding IPSec SAs cleared (1 times)
    Mon Jul 26 2021 07:17:48: IPSec SA negotiation successfully completed (1 times)
    Mon Jul 26 2021 07:17:41: User cleared IKE SA from CLI, corresponding IPSec SAs cleared (1 times)
    Mon Jul 26 2021 07:15:25: IPSec SA negotiation successfully completed (1 times)
    Mon Jul 26 2021 07:15:25: Tunnel configuration changed. Corresponding IKE/IPSec SAs are deleted (1 times)
    Mon Jul 26 2021 07:10:48: Negotiation failed with error code NO_PROPOSAL_CHOSEN received from peer (2 times)
    Mon Jul 26 2021 03:33:47: IKE SA negotiation successfully completed (1 times)
    Mon Jul 26 2021 03:33:23: No response from peer. Negotiation failed (1 times)
    Sun Jul 25 2021 23:42:47: IKE SA negotiation successfully completed (1 times)
    Sun Jul 25 2021 23:42:24: No response from peer. Negotiation failed (1 times)
    Sun Jul 25 2021 23:41:48: Peer proposed traffic-selectors are not in configured range (1 times)
    Sun Jul 25 2021 19:51:30: IKE SA rekey successfully completed (1 times)
    Direction: inbound, SPI: 7a09f54, AUX-SPI: 0
    , VPN Monitoring: -
    Hard lifetime: Expires in 2582 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 1971 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64
    Direction: outbound, SPI: c8772c89, AUX-SPI: 0
    , VPN Monitoring: -
    Hard lifetime: Expires in 2582 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 1971 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Both the 6wind concentrator and juniper srx are showing outbound encrypted bytes bot no decrypted received bytes.

    root@PR_KUL_CR01> show security ipsec statistics
    ESP Statistics:
    Encrypted bytes: 366548
    Decrypted bytes: 0
    Encrypted packets: 2350
    Decrypted packets: 0
    AH Statistics:
    Input bytes: 0
    Output bytes: 0
    Input packets: 0
    Output packets: 0

    Running a ping from my device to our DC shows the bytes leaving the device but never ending op on the concentrator:

    root@PR_KUL_CR01% tcpdump -i st0.0
    verbose output suppressed, use <detail> or <extensive> for full protocol decode
    Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
    Address resolution timeout is 4s.
    Listening on st0.0, capture size 96 bytes

    Reverse lookup for 10.33.6.1 failed (check DNS reachability).
    Other reverse lookup failures will not be reported.
    Use <no-resolve> to avoid reverse lookups on IP addresses.

    08:51:51.722708 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 55999, seq 340, length 64
    08:51:51.918764 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 56208, seq 8, length 64
    08:51:52.723712 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 55999, seq 341, length 64
    08:51:52.919757 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 56208, seq 9, length 64
    08:51:53.724523 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 55999, seq 342, length 64
    08:51:53.920515 Out IP truncated-ip - 10 bytes missing! 10.33.6.1 > 10.10.8.103: ICMP echo request, id 56208, seq 10, length 64
    ^C
    6 packets received by filter
    0 packets dropped by kernel

    Any idea if we might be forgetting something or if there is a misconfiguration somewhere?



    ------------------------------
    Gianni Stubbe
    ------------------------------


  • 2.  RE: Unable to transfer traffic over route based ipsec vpn with established PH2

    Posted 07-26-2021 05:56
    I'm not familiar with 6wind but it looks like the networks for the proxy id are mismatched.
    6Wind
            security-policy hub8
    local-ts subnet 10.10.8.0/23
    remote-ts subnet 0.0.0.0/0
    SRX
    traffic-selector DC {
    local-ip 10.33.6.0/23;
    remote-ip 10.10.8.0/23;
    When using proxy-id on the SRX the expectation is the match on both sides so the 6wind would need 10.10.8.0/23 instead of 0.0.0.0/0

    By default with route based VPN (the SRX preferred method) your proxy id pair would be 0.0.0.0/0 on both sides and then your routing configuration chooses what traffic is sent to the tunnel instead of the vpn proxy configuration.

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



  • 3.  RE: Unable to transfer traffic over route based ipsec vpn with established PH2

    Posted 07-26-2021 08:19

    Thanks,  we will try this but this was working with our Fortigate appliances without issue.

    So we should be setting 0.0.0.0 as local subnet on the srx or set 10.33.6.0/28 on the 6Wind appliance?



    ------------------------------
    Gianni Stubbe
    ------------------------------



  • 4.  RE: Unable to transfer traffic over route based ipsec vpn with established PH2

    Posted 07-26-2021 20:12
    With traffic selectors you would be best to use 10.33.6.0/28 as it creates a route to push traffic into the tunnel and I assume you don't want a default route going into the tunnel.

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