Juniper SRX – Point-To-Site IPsec VPN Setup

ipsecjuniper-srxlinux

I'm trying to setup an IPsec VPN tunnel between a Debian Jessie system running strongSwan and an SRX. The end goal is to use the Debian host as a reverse-proxy for hosts behind the SRX, which I assume will require a split-tunnel.

The Debian host is debian.example.com/1.2.3.4.

The SRX is at srx.example.com and has a dynamically assigned IP which I've replaced with 5.6.7.8 below.

Both sides seem to think the SA is up, but I am unable to ping anything in the 192.168.1.0/24 subnet from the Debian host.

SRX:

root@srx# run show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
3981725 UP     b1cbd62070dd2779  f49d3bd11b69a018  IKEv2          1.2.3.4

Debian:

# ipsec status srx.example.com
Security Associations (1 up, 0 connecting):
srx.example.com[1]: ESTABLISHED 32 minutes ago, 1.2.3.4[debian.example.com]...5.6.7.8[srx.example.com]
srx.example.com{1}:  INSTALLED, TUNNEL, ESP SPIs: ca2f0887_i 516e8cf8_o
srx.example.com{1}:   192.168.2.0/24 === 192.168.1.0/24
# ip -s xfrm policy list src 192.168.2.0/24
src 192.168.2.0/24 dst 192.168.1.0/24 uid 0
        dir out action allow index 2593 priority 2883 ptype main share any flag  (0x00000000)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 0(sec), hard 0(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          0(bytes), 0(packets)
          add 2016-08-16 18:14:21 use -
        tmpl src 1.2.3.4 dst 5.6.7.8
                proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel
                level required share any
                enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff

SRX config:

interfaces {
    interface-range interfaces-trust {
        member fe-0/0/0;
        member fe-0/0/1;
        member fe-0/0/2;
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/7 {
        unit 0 {
            family inet {
                dhcp {
                    update-server;
                }
            }
        }
    }
    st0 {
        unit 0 {
            family inet;
        }
    }
    vlan {
        unit 100 {
            family inet {
                address 192.168.1.1/24;
            }
        }
    }
}
security {
    ike {
        proposal ike-vpn-proposal {
            authentication-method pre-shared-keys;
            dh-group group24;
            authentication-algorithm sha-256;
            encryption-algorithm aes-128-cbc;
        }
        policy ike-vpn-policy {
            mode aggressive;
            proposals ike-vpn-proposal;
            pre-shared-key ascii-text "$9$KJiWxdaJDkqf7-qfQzAtNdb"; ## SECRET-DATA
        }
        gateway vpn-local-gw {
            ike-policy ike-vpn-policy;
            address 1.2.3.4;
            local-identity hostname srx.example.com;
            remote-identity hostname debian.example.com;
            external-interface fe-0/0/7.0;
            version v2-only;
        }
    }
    ipsec {
        proposal ipsec-vpn-proposal {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-128-cbc;
        }
        policy ipsec-vpn-policy {
            perfect-forward-secrecy {
                keys group24;
            }
            proposals ipsec-vpn-proposal;
        }
        vpn vpn {
            bind-interface st0.0;
            ike {
                gateway vpn-local-gw;
                proxy-identity {
                    local 192.168.1.0/24;
                    remote 192.168.2.0/24;
                }
                ipsec-policy ipsec-vpn-policy;
            }
            establish-tunnels immediately;
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone trust {
            policy untrust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    deny;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.100;
            }
        }
        security-zone untrust {
            screen untrust-screen;
            interfaces {
                fe-0/0/7.0 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                            ike;
                        }
                    }
                }
            }
        }
        security-zone vpn {
            interfaces {
                st0.0;
            }
        }
    }
}
vlans {
    vlan-trust {
        vlan-id 100;
        l3-interface vlan.100;
    }
}

Debian strongSwan config:

# ipsec.conf - strongSwan IPsec configuration file

config setup

# Add connections here.
conn srx.example.com
    auto=start
    keyexchange=ikev2
    authby=secret
    ike=aes128-sha256-modp2048s256
    ikelifetime=3h
    esp=aes128-sha256
    leftid=@debian.example.com
    rightid=@srx.example.com
    left=1.2.3.4
    right=srx.example.com
    leftsubnet=192.168.2.0/24
    rightsubnet=192.168.1.0/24

include /var/lib/strongswan/ipsec.conf.inc

Update:

I think I may be missing the routes to make things work.

SRX:

root@srx> show security flow session destination-prefix 192.168.1.0
Total sessions: 0

root@dravis> show route table inet.0 brief

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Access-internal/12] 22:20:39
                    > to 5.6.7.1 via fe-0/0/7.0
5.6.7.0/24         *[Direct/0] 10w3d 12:43:15
                    > via fe-0/0/7.0
5.6.7.8/32         *[Local/0] 10w3d 12:43:15
                      Local via fe-0/0/7.0
192.168.1.0/24     *[Direct/0] 4w6d 13:21:42
                    > via vlan.100
192.168.1.1/32     *[Local/0] 10w3d 12:43:40
                      Local via vlan.100

Debian:

$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         1.2.3.1         0.0.0.0         UG        0 0          0 eth0
10.10.0.0       0.0.0.0         255.255.0.0     U         0 0          0 eth0
1.2.3.0         0.0.0.0         255.255.255.0   U         0 0          0 eth0

Best Answer

On the SRX you have no security policy configured between the vpn zone (which is where your tunnel interface st0.0 resides) and the trust zone.

Add the following and you should be up and running:

set security policies from-zone vpn to-zone trust policy vpn-to-trust match source-address any
set security policies from-zone vpn to-zone trust policy vpn-to-trust match destination-address any
set security policies from-zone vpn to-zone trust policy vpn-to-trust match application any
set security policies from-zone vpn to-zone trust policy vpn-to-trust then permit

Related Solutions

Vpn – Juniper SRX to SRX site-to-site VPN over existing WAN in trust zone

Actually I think most of what you are trying to achieve is answered in that document: http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf

Since this kind of setup requires two routing instances (one flow based and another packet based) you should be able to use a local "LAN" IP on both sides of the SRX as long as you use two different interfaces.

The SRXes you need to use must be of "HighMemory" type IE: SRX100H (not SRX100B) to be able to support GRE fragmentation.

VPN – How to Set Up Backup IP for Site-to-Site VPN on Juniper SRX?

Junos does have DPD and you can use it in conjunction with multiple endpoint IP addresses in a single IKE tunnel.

There is a bit of info about it here (which I've copied below)

http://kb.juniper.net/InfoCenter/index?page=content&id=KB29211&actp=RSS

SUMMARY: This article explains how redundancy in site-to-site VPN can be achieved using multiple address in gateway and dead-peer-detection.

PROBLEM OR GOAL: How to use different modes of dead-peer-detection for VPN failover .

CAUSE:

SOLUTION: The gateway for VPN redundancy can be configured with the following commands :

set interfaces fe-0/0/0 unit 0 family inet address 1.1.1.2/24
set interfaces st0 unit 0 family inet
set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
set security ike policy p1 mode main
set security ike policy p1 proposal-set standard
set security ike policy p1 pre-shared-key ascii-text "$9$21oZjmfzCtOHqtO1RlegoJ"
set security ike gateway g1 ike-policy p1
set security ike gateway g1 address 2.2.2.1
set security ike gateway g1 address 3.3.3.1
set security ike gateway g1 dead-peer-detection interval 10
set security ike gateway g1 dead-peer-detection threshold 3
set security ike gateway g1 external-interface fe-0/0/0
set security ipsec policy p1 proposal-set standard
set security ipsec vpn v1 bind-interface st0.0
set security ipsec vpn v1 ike gateway g1
set security ipsec vpn v1 ike ipsec-policy p1
set security ipsec vpn v1 establish-tunnels immediately

The first address in the order of configuration is the one chosen to negotiate the tunnel:

gateway g1 {
            ike-policy p1;
            address [ 2.2.2.1 3.3.3.1 ];
            dead-peer-detection {
                                 interval 10;
                                 threshold 3;
                                 }
            external-interface fe-0/0/0;
            }

The above configuration is in dead-peer-detection optimal mode. It sends probes if packets were sent out (encrypted packets), but no packets were received (decrypted) for the configured interval. Three probe-packets are sent at 10 second intervals.

root@srx# run show security ike sa 
Index State Initiator cookie Responder cookie Mode Remote Address 
6770125 UP d570a30c806721ea ccc1572d2f763981 Main 2.2.2.1 


root@srx# run show security ipsec sa 
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway 
<131073 ESP:3des/sha1 1debda06 3397/ unlim - root 500 2.2.2.1 
>131073 ESP:3des/sha1 7a7dff24 3397/ unlim - root 500 2.2.2.1

As soon as the tunnel drops, dead-peer-detection comes into play. If a response is not received from the peer in 30 seconds, the failover takes place and the tunnel is negotiated with 3.3.3.1 and vice-versa.

root@srx# run show security ike sa
Index State Initiator cookie Responder cookie Mode Remote Address 
6770151 UP 36a2e145e0fd2c10 b3abc0b135cf33fe Main 3.3.3.1

root@srx# run show security ipsec sa 
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway 
<131073 ESP:3des/sha1 2420b2bd 3598/ unlim - root 500 3.3.3.1 
>131073 ESP:3des/sha1 5c8bb9da 3598/ unlim - root 500 3.3.3.1

Always-Send mode for dead-peer-detection:

In order to instruct the device to send dead-peer-detection requests, regardless of whether or not there is outgoing IPSec traffic to the peer, the following command is also needed:

set security ike gateway g1 dead-peer-detection always-send

UPDATE

I have configured this in a test lab and confirm that it works well. I have 3 devices, S3, S4 and S5.

S4 and S5 both have a basic IPSEC tunnel configured to connect to S3 (7.7.7.22 in my example). The config is dead simple and the same on both devices

ike {
    gateway s3-gw {
        ike-policy ike-policy;
        address 7.7.7.22;
        external-interface ge-0/0/1.0;
    }
}
ipsec {
    policy standard-ipsec-policy {
        proposal-set standard;
    }
    vpn s3 {
        bind-interface st0.0;
        ike {
            gateway s3-gw;
            ipsec-policy standard-ipsec-policy;
        }
        establish-tunnels immediately;
    }
}

The device S3 has a config that is very similar to the above but has 2 gateways listed and DPD enabled.

The relevant section is in the IKE config

gateway s4-s5-gw {
    address [ 7.7.7.21 192.168.211.2 ];
    dead-peer-detection {
        always-send;
        interval 10;
        threshold 3;
    }
    external-interface ge-0/0/1.0;
}

This brings up the tunnel as such

root@TEST-srx3> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
1404200 UP     2f4f0465dc8c4556  d2e6022d0dc213c3  Main           7.7.7.21

root@TEST-srx3> show security ipsec sa
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131073 ESP:3des/sha1 d4428f3  3170/ unlim   -   root 500   7.7.7.21
  >131073 ESP:3des/sha1 5cda9108 3170/ unlim   -   root 500   7.7.7.21

If I deactivate the IKE/IPSEC config sections on S4 the tunnel drops and then comes back up connected to the 2nd gateway

root@TEST-srx3> show security ike security-associations

root@TEST-srx3> show security ipsec sa
  Total active tunnels: 0

Then after about 30 seconds (10 x 3)

root@TEST-srx3> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
1404202 UP     35e54d457be6132f  0444ae31577c71a2  Main           192.168.211.2

root@TEST-srx3> show security ipsec sa
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131073 ESP:3des/sha1 93043b2  3595/ unlim   -   root 500   192.168.211.2
  >131073 ESP:3des/sha1 e5c551e4 3595/ unlim   -   root 500   192.168.211.2

If you need any help post some config snippets and I'll do my best to have a look!

UPDATE 2

I have built this whole thing in a mini lab. The problem I have found is that while you can use multiple gateways in your IKE configuration you will still need to have an IPSEC tunnel per ISP on each device. This is because you have multiple source IP addresses you want to potentially make an IPSEC tunnel from.

Lab Config

To save me posting a lot of config each SRX (A and B) has two IPSEC tunnels configured as shown below. The things to note are I'm using a single tunnel interface on each device, these are set to multipoint. You could use multiple ones if you wanted.

This config will provide full redundancy if a single ISP at site A and/or site B goes down.

I tested this by dropping the linked between SRX-A and SRX-1 and then dropping SRX-B and SRX-4. Due to me using BGP and DPD it took just over a minute for the tunnel to come back up but worked well!

Hopefully this will ultimately help you sort out your config!

SRX-A IPSEC Config

ike {
    gateway SRX-B_via_ISP1 {
        ike-policy ike-policy;
        address [ 6.6.6.6 5.5.5.5 ];
        dead-peer-detection {
            always-send;
            interval 10;
            threshold 3;
        }
        external-interface lo0.10;
        local-address 7.7.7.5;
    }
    gateway SRX-B_via_ISP2 {
        ike-policy ike-policy;
        address [ 6.6.6.6 5.5.5.5 ];
        dead-peer-detection {
            always-send;
            interval 10;
            threshold 3;
        }
        external-interface lo0.10;
        local-address 8.8.8.9;
    }
}
ipsec {
    policy standard-ipsec-policy {
        proposal-set standard;
    }
    vpn SRX-B_via_ISP1 {
        bind-interface st0.0;
        ike {
            gateway SRX-B_via_ISP1;
            ipsec-policy standard-ipsec-policy;
        }
        establish-tunnels immediately;
    }
    vpn SRX-B_via_ISP2 {
        bind-interface st0.0;
        ike {
            gateway SRX-B_via_ISP2;
            ipsec-policy standard-ipsec-policy;
        }
        establish-tunnels immediately;
    }
}

Best Answer

Related Solutions

Vpn – Juniper SRX to SRX site-to-site VPN over existing WAN in trust zone

VPN – How to Set Up Backup IP for Site-to-Site VPN on Juniper SRX?

Related Topic