andkorn.org

a fine line between curiosity and madness.

Juniper SRX Policy-Based VPN and Route-Based VPN

Let me start by saying both Juniper and Cisco have excellent publicly available documentation. However, just like with any vendor, documentation on interoperability is always lacking. Making two products work together peacefully is your job as the Network Engineer, and the manufacturer is only going to help you so far. That’s why you have years of experience under your belt!

Both Juniper and Cisco support Policy-based VPNs (more common) and Route-based VPNs (less common, but much more useful). More people know how to set up Policy-based VPNs and they are also more vendor-neutral. But there are plenty of reasons you don’t want a Policy-based VPN (from here on referred to as a PBVPN) and you should use a Route-based VPN.

  • For Cisco people: Policy-based VPN uses Access-lists, Route-based VPN uses interface Tunnel0 (virtual tunnel interface aka VTI).
  • Juniper: Policy-based VPN uses policies and pair-policy, Route-based VPN uses interface st0 (Secure Tunnel 0).

Let’s start by going through some pros and cons of each. This list was compiled from Juniper, Fortinet (PDF doc) and Firewall.cx](http://www.firewall.cx/cisco-technical-knowledgebase/cisco-services-tech/945-cisco-comparing-vpn-technologies.html) documentation but has my own additions.

Policy-based VPN (PBVPN)

Pros:

  • More vendor-neutral
  • More people know it, and therefore seems to be easier to setup
  • Most site-to-site VPNs that you see will be PBVPNs.

Cons:

  • May run into NAT issues; May need to specifically bypass NAT on some devices
  • Limited QoS
  • No support for traffic other than IP
  • No Dynamic Routing such as OSPF or RIP
  • In some cases may be difficult to troubleshoot
  • Need to have proxy-id match up properly on both sides of the VPN

Route-based VPN

Pros:

  • Easy to setup and understand. Creates a virtual interface that you can route to
  • Supports traffic other than IP
  • Supports Dynamic Routing such as OSPF or RIP
  • Supports QoS
  • Supports routing fail-over
  • No need to bypass NAT

Cons:

  • Less vendor-neutral
  • Usually only supported between two devices of the same manufacturer. However, it is possible to get them to work, and work reliably. I have had success with Route-based VPNs between Juniper and Sonicwall; I have seen Cisco to Juniper Route-based VPNs.
  • In order to lock down the VPN to specific hosts/ports/etc, you have to define extra security policies/access lists.
  • Not as many people know Route-based VPNs

Now let’s cover what is needed to implement each type. I will use the codenames Alpha to refer to the local site, and Beta to refer to the remote site.

Alpha (local site)

  • Public IP: 123.192.168.1
  • Local Network: 192.168.1.0/24
  • WAN interface: ge-0/0/0.0 or ge0/0 (123.192.168.1)
  • LAN interface: ge-0/0/1.0 or ge0/1 (192.168.1.1)

Beta (remote site)

  • Public IP: 123.10.0.1
  • Local Network: 10.0.0.0/24
  • WAN interface: ge-0/0/0.0 or ge0/0 (123.10.0.1)
  • LAN interface: ge-0/0/1.0 or ge0/1 (10.0.0.1)

Policy-based VPN on Juniper

  • Interfaces
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
interfaces {
  ge-0/0/0 {
  description WAN;
  unit 0 {
      family inet {
          address 123.192.168.1/30;
      }
  }
  ge-0/0/1 {
  description LAN;
  unit 0 {
      family inet {
          address 192.168.1.1/24;
      }
  }
}
1
2
set security zone security-zone untrust interfaces ge-0/0/0.0
set security zone security-zone trust interfaces ge-0/0/1.0
  • Define the IKE (Phase 1) and IPsec (Phase 2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
security {
  ike {
      proposal psk-mainmode-dhg2-aes256-sha256 {
          authentication-method pre-shared-keys;
          dh-group group2;
          authentication-algorithm sha-256;
          encryption-algorithm aes-256-cbc;
          lifetime-seconds 28800;
      }

      policy ikeALPHA-to-BETA {
          mode main;
          proposals psk-mainmode-dhg2-aes256-sha256;
          pre-shared-key ascii-text "MY-PRE-SHARED-KEY";
      }
      
      gateway gwALPHA-to-BETA {
          ike-policy ikeALPHA-to-BETA;
          address 123.10.0.1;
          external-interface ge-0/0/0.0;
      }
  }
  
  ipsec {
      proposal esp-aes256-sha256 {
          protocol esp;
          authentication-algorithm hmac-sha-256-128;
          encryption-algorithm aes-256-cbc;
          lifetime-seconds 3600;
      }

      vpn vpnALPHA-to-BETA {
          ike {
              gateway gwALPHA-to-BETA;
              ipsec-policy esp-aes256-sha256;
          }
      }
  }
}
  • Define the security policies so the traffic gets encrypted as it gets transported to the other side, and is decrypted as it is received.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
security {
  policies {
      from-zone trust to-zone untrust {
          policy vpn-out-ALPHA-to-BETA {
              match {
                  source-address addr_ALPHANET;
                  destination-address addr_BETANET;
                  application any;
              }
              then {
                  permit {
                      tunnel {
                          ipsec-vpn vpnALPHA-to-BETA;
                          pair-policy vpn-in-ALPHA-to-BETA;
                      }
                  }
              }
          }
      }
      
      from-zone untrust to-zone trust {
          policy vpn-in-ALPHA-to-BETA {
              match {
                  source-address addr_BETANET;
                  destination-address addr_ALPHANET;
                  application any;
              }
              then {
                  permit {
                      tunnel {
                          ipsec-vpn vpnALPHA-to-BETA;
                          pair-policy vpn-out-ALPHA-to-BETA;
                      }
                  }
              }
          }
      }
  }
}
  • Make sure the two policies are at the TOP of the policies in their zones. Policies are matched in a top-down fashion, and if the traffic matches something before the VPN policy it will NOT be encrypted. This can be achieved via:
1
2
insert security policies from-zone trust to-zone untrust policy policy vpn-out-ALPHA-to-BETA before policy CURRENT-FIRST-POLICY
insert security policies from-zone untrust to-zone trust policy policy vpn-in-ALPHA-to-BETA before policy CURRENT-FIRST-POLICY
  • Define your address objects (referenced in the policies above):
1
2
set security zones security-zone trust address-book address addr_ALPHANET 192.168.1.0/24
set security zones security-zone untrust address-book address addr_BETANET 10.0.0.0/24
  • Bypass NAT. I did you a favor and listed all private subnets, you may want to adjust to taste based on your NAT rules:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
security {
  nat {
      source {
          rule-set trust-to-untrust {
              rule bypass-nat {
                  match {
                      destination-address [ 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12 ];
                  }
                  then {
                      source-nat {
                          off;
                      }
                  }
              }
          }
      }
  }
}
  • Phew! That was not fun.

Route-based VPN on Juniper

  • Interfaces
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
interfaces {
  ge-0/0/0 {
  description WAN;
  unit 0 {
      family inet {
          address 123.192.168.1/30;
      }
  }
  ge-0/0/1 {
  description LAN;
  unit 0 {
      family inet {
          address 192.168.1.1/24;
      }
  }
  st0 {
      unit 0 {
          description VPNtun-ALPHA-to-BETA;
          family inet {
              address 172.123.123.0/31;
          }
      }
  }
}
1
2
3
set security zone security-zone untrust interfaces ge-0/0/0.0
set security zone security-zone trust interfaces ge-0/0/1.0
set security zone security-zone trust interfaces st0.0
  • Define the IKE (Phase 1) and IPsec (Phase 2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
security {
  ike {
      proposal psk-mainmode-dhg2-aes256-sha256 {
          authentication-method pre-shared-keys;
          dh-group group2;
          authentication-algorithm sha-256;
          encryption-algorithm aes-256-cbc;
          lifetime-seconds 28800;
      }

      policy ikeALPHA-to-BETA {
          mode main;
          proposals psk-mainmode-dhg2-aes256-sha256;
          pre-shared-key ascii-text "MY-PRE-SHARED-KEY";
      }
      
      gateway gwALPHA-to-BETA {
          ike-policy ikeALPHA-to-BETA;
          address 123.10.0.1;
          external-interface ge-0/0/0.0;
      }
  }
  
  ipsec {
      proposal esp-aes256-sha256 {
          protocol esp;
          authentication-algorithm hmac-sha-256-128;
          encryption-algorithm aes-256-cbc;
          lifetime-seconds 3600;
      }

      vpn vpnALPHA-to-BETA {
          bind-interface st0.0;
          ike {
              gateway gwALPHA-to-BETA;
              ipsec-policy esp-aes256-sha256;
          }
      }
  }
}
  • Define routing. Note that this will send the traffic out over st0.0, which is what we want:
1
set routing-options static route 10.0.0.0/24 next-hop 172.123.123.1
  • Much better!

Policy-based VPN and Route-based VPN on Cisco

  • I don’t have a Cisco ASA or ISR handy right now, so I will have to refer you to the excellent Firewall.cx Cisco article. You can also find the article in the See Also section below.

See Also

Comments