SRX

I am trying to configure an IPv4 IPSec VPN, where the IKE negotiations take place on an external interface, on a remote SRX 345, that is NOT in the global inet.0, and the route handling behavior between the global routing instance and virtual routing instances is causing me headaches.

The external interface where the IKE negotiations take place is in VR1.inet.0.  But I want the VPN to be in another separate virtual routing instance, VR2.inet.0.

I can get the IKE and IPSec tunnel to come up just fine, but I am unable to route traffic through the st0.1 interface. There appears to be a limitation here, due to the fact that I am not using the global inet.0.

In my diagram below, I show how I am able to get a management VPN to this SRX 345, where the tunnel st0.0 resides in the global inet.0, using a virtual routing instance VR1.inet.0 for the IKE negotiations. It works just fine, and I am able to route traffic through st0.0. But if I try to setup a new VPN, with endpoints in VR2.inet.0, the VPN comes up, but I can not seem to route traffic across the VPN.

The reason why the user traffic is in a separate VR1.inet.0, from inet.0, is because I want to keep management traffic separate from user traffic. Likewise, in the new VR2.inet.0, I want to keep traffic separate from management (inet.0) and the other virtual router (VR1.inet.0).

Any clues on how to do this? Can the SRX 345 support such a configuration?

Existing Config code snippet:

.

security {
    ike {
        policy DYNAMIC {
            mode aggressive;
            proposal-set standard;
            pre-shared-key ascii-text "abcdefg"; ## SECRET-DATA
        }
        gateway Interwebs-Mgmt {
            ike-policy DYNAMIC;
            address 1.1.18.5;
            dead-peer-detection {
                always-send;
                interval 30;
                threshold 5;
            }
            local-identity hostname remote.test.net;
            external-interface irb.3;
        }
        gateway Interwebs-ForNewVPN {
            ike-policy DYNAMIC;
            address 1.1.3.25;
            dead-peer-detection {
                always-send;
                interval 30;
                threshold 5;
            }
            local-identity hostname remote.test.net;
            external-interface irb.3;
        }
    }
    ipsec {
        policy IPSEC-POLICY {
            proposal-set standard;
        }
        vpn VPN-Interwebs-Mgmt {
            bind-interface st0.0;
            df-bit clear;
            ike {
                gateway Interwebs-Mgmt;
                ipsec-policy IPSEC-POLICY;
            }
            establish-tunnels immediately;
        }
        vpn VPN-Interwebs-ForNewVPN {
            bind-interface st0.1;
            df-bit clear;
            ike {
                gateway Interwebs-ForNewVPN;
                ipsec-policy IPSEC-POLICY;
            }
            establish-tunnels immediately;
        }
    }
}
interfaces {
    irb {
        unit 2 {
            description ForNewVPN;
            family inet {
                address 172.16.120.1/24;
            }
        }
        unit 3 {
            description Interwebs;
            family inet {
                dhcp-client;
            }
        }
        unit 120 {
            description Users;
            family inet {
                address 192.168.120.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.4.120.1/32;
            }
        }
    }
    st0 {
        unit 0 {
            description Tunnel-Mgmt;
            family inet;
        }
        unit 1 {
            description Tunnel-ForNewVPN;
            family inet;
        }
    }
}

routing-options {
    static {
        route 0.0.0.0/0 next-hop st0.0;
    }
}
routing-instances {
    ForNewVPN {
        instance-type virtual-router;
        interface irb.2;
        interface st0.1;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop st0.1;
            }
        }
    }
    InternetVR {
        instance-type virtual-router;
        interface irb.3;
        interface irb.120;
    }
}

.

Here is the relevant CLI output that I am working with:

.

testrtr@SRX345# run show security ike security-associations 
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
2313162 UP     ea9a53a94d1f9d9d  3c45162b53d0acec  Aggressive     1.1.3.25    
2313163 UP     05d2b1363c5dbd55  02ff3ab036a4fecb  Aggressive     1.1.18.5    

[edit]
testrtr@SRX345# run show security ipsec security-associations  
  Total active tunnels: 2
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131054 ESP:3des/sha1 f43ff651 1994/ unlim   -   root 500   1.1.3.25    
  >131054 ESP:3des/sha1 4e258f1f 1994/ unlim   -   root 500   1.1.3.25    
  <131053 ESP:3des/sha1 f8b22305 1985/ unlim   -   root 500   1.1.18.5    
  >131053 ESP:3des/sha1 462bd8f2 1985/ unlim   -   root 500   1.1.18.5    

[edit]
testrtr@SRX345# run show route                                   

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

0.0.0.0/0          *[Static/5] 02:56:02
                    > via st0.0
10.4.120.1/32      *[Direct/0] 3d 18:23:25
                    > via lo0.0
10.255.0.0/16       *[Direct/0] 4d 22:05:25
                    > via fxp0.0
10.255.10.21/32    *[Local/0] 4d 22:05:25
                      Local via fxp0.0

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

172.16.120.0/24   *[Direct/0] 02:56:26
                    > via irb.2
172.16.120.1/32   *[Local/0] 23:46:30
                      Local via irb.2

>>>>>>>>> Default route is missing through st0.1   !!!! <<<<<<<<<<<<<<<<<<
>>>>>>>>> Where did it go????                      !!!! <<<<<<<<<<<<<<<<<<


VR1.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] 02:56:05
                    > to 8.8.3.1 via irb.3
8.8.3.0/24     *[Direct/0] 02:56:12
                    > via irb.3
8.8.3.46/32    *[Local/0] 02:56:12
                      Local via irb.3
192.168.120.0/24   *[Direct/0] 02:56:28
                    > via irb.120
192.168.120.1/32   *[Local/0] 4d 21:28:04
                      Local via irb.120

You have IKE physical in one Routing-Instance and the st0.1 in another routing-instance. Do you have policies between the two VRs?

Is st0.1 showing as UP UP?

Are you able to have a default of 0.0.0.0/0 in two different routing tables? I've never tried it so don't know.

I do not need policies between the two VRs, because I am not running traffic between them.  I know you can put the IKE in the global routing instance, and the st interface in a VR, or vice-versa: put the IKE in a VR and the st interface in the global routing instance (as I already have).

What I am not sure about is if I can put the IKE in one VR, and the st interface in another separate VR..... unless there was some way I could leak routes with rib groups, to get this to work.

Yes, st0.1 is showing UP UP.

In principle, it seems like you should be able to do with a VR whatever you can do with the global routing instance.  But, then, maybe not???

And, yes, you can 0.0.0.0/0 show up in as many different routing tables as you want.

I did deploy a remote site a few years ago where the ike was with the ISP in the master routing instance and the tunnel interface st0 inside a virtual router routing instance using a default route to the tunnel to bring all internet traffic back to the core data center site.  So I know this can work.

It is odd that the default route is not up with the tunnel interface in up/up status.  Will any route to this tunnel work in this VR?

I wonder if the security zone assignments and policies may be at play.

The IKE in one VR and the st0.1 interface in another VR is exactly what I have done, but I had to have a policy linking the 2 VRs.... or, as you have mentioned, you may possibly have to route leak beween the VRs, but I'm not too sure that would help with the actual IPSec tunnel setup itself.

My setup was as follows:

VPN-VR: Physical interface with address in IKE for associations

Customer-VR: Data end point st0.1 interface

Customer-VR contains the route back through the st0.1 interface for the Subnet VPN addresses.

Policy linking the two-zones for the IKE to st0.1 association.

You have a default route in the VR that is not appearing, this is why I was asking if you can have a default route in two separate VRs?

If you can, then surely the one placed in the VR will only place all traffic to the VR into the st0.1 interface?

As to why the default route is not appearing in the routing table, I don't know.

If you want my config snippets for the config then please let me know, but it works for me.

Yes, please I would like to see your config snippets. Do you mind posting here?

Clarke Morledge

College of William and Mary

Here's the configuration I have used. I don't think I have missed anything:

1: NCP Secure Client Configuration:

set security ike proposal ncp-proposal authentication-method pre-shared-keys
set security ike proposal ncp-proposal dh-group group2
set security ike proposal ncp-proposal authentication-algorithm sha1
set security ike proposal ncp-proposal encryption-algorithm aes-192-cbc
set security ike proposal ncp-proposal lifetime-seconds 10800

set security ike policy ncp-policy mode aggressive
set security ike policy ncp-policy proposals ncp-proposal
set security ike policy ncp-policy pre-shared-key ascii-text

set security ike gateway ncp-gateway ike-policy ncp-policy
set security ike gateway ncp-gateway dynamic user-at-hostname "test@ncp.juniper.net"
set security ike gateway ncp-gateway dynamic connections-limit 10
set security ike gateway ncp-gateway dynamic ike-user-type shared-ike-id
set security ike gateway ncp-gateway external-interface ge-0/0/1
set security ike gateway ncp-gateway aaa access-profile radius
set security ike gateway ncp-gateway version v1-only
set security ike gateway ncp-gateway tcp-encap-profile NCP

set security ipsec proposal ncp-ipsec-proposal protocol esp
set security ipsec proposal ncp-ipsec-proposal authentication-algorithm hmac-sha1-96
set security ipsec proposal ncp-ipsec-proposal encryption-algorithm aes-128-cbc
set security ipsec proposal ncp-ipsec-proposal lifetime-seconds 3600

set security ipsec policy ncp-ipsec-policy perfect-forward-secrecy keys group2
set security ipsec policy ncp-ipsec-policy proposals ncp-ipsec-proposal

set security ipsec vpn ncp-ipsec-vpn bind-interface st0.1
set security ipsec vpn ncp-ipsec-vpn ike gateway ncp-gateway
set security ipsec vpn ncp-ipsec-vpn ike idle-time 900
set security ipsec vpn ncp-ipsec-vpn ike ipsec-policy ncp-ipsec-policy
set security ipsec vpn ncp-ipsec-vpn traffic-selector TS1 local-ip 0.0.0.0/0
set security ipsec vpn ncp-ipsec-vpn traffic-selector TS1 remote-ip 0.0.0.0/0

2: Address book entry for VPN-Pool:

set security address-book global address ncp-vpn-pool 172.16.10.0/24

3: Security Policies required between the zones (as I am using Logical tunnels I only ever need the policies from and to the same zone, not between the zones):

set security policies from-zone Customer-Network to-zone Customer-Network policy customertocustomer match source-address any
set security policies from-zone Customer-Network to-zone Customer-Network policy customertocustomer match destination-address any
set security policies from-zone Customer-Network to-zone Customer-Network policy customertocustomer match application any
set security policies from-zone Customer-Network to-zone Customer-Network policy customertocustomer then permit
set security policies from-zone Customer-Network to-zone Customer-Network policy customertocustomer then log session-init

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

4: Security Zones Configuration:

set security zones security-zone Customer-Network interfaces st0.1

set security zones security-zone restapivpn interfaces ge-0/0/1.0

5: Routing Instance configuration (snippet for VPN only):

set routing-instances Customer-VR instance-type virtual-router
set routing-instances Customer-VR interface st0.1
set routing-instances Customer-VR routing-options static route 172.16.10.0/24 next-hop st0.1

set routing-instances restapivpn instance-type virtual-router
set routing-instances restapivpn interface ge-0/0/1.0

As you can see, the physical interface is one VR and the Logical st interface is in another VR. But to make it work, I still had to have a policy between the two and I have NO traffic other than the VPN traversing the two. I just wanted to make the VPN more secure and have the data exit point in the right VR.

Hope this helps

That looks like a dynamic remote access vpn.  The setup here is for site to site vpn with the tunnel interface in a routing instance.

The actual VR configuration for the endpoints is the same though. 

The config is the same (other than the IKE) for our site-to-site VPNs too. The physical and logical interfaces are in different VRs.

Here is the site-to-site for Azure, for example:

set security ike gateway azure-gateway external-interface ge-0/0/1
set security ipsec vpn azure-ipsec-vpn bind-interface st0.0
set security address-book global address azure-networks-1 30.200.2.0/24
set security address-book global address azure-networks-2 30.200.3.0/24
set security zones security-zone Customer-Network interfaces st0.0
set security zones security-zone restapivpn interfaces ge-0/0/1.0
set routing-instances Customer-VR routing-options static route 30.200.2.0/24 next-hop st0.0
set routing-instances Customer-VR routing-options static route 30.200.3.0/24 next-hop st0.0
set routing-instances restapivpn interface ge-0/0/1.0

The policy is the same.... the only difference is where you're routing to and the next-hop.

Thanks, adgwytc.

I had an interface configuration issue, and your template helped me to find my error. Things are working as expected now.