SRX

Hello,

I am posting to the forum for help with a couple issues.

**I have attached all the VPNs for the SSG-520**

My predecessor set up the VPN’s on this SSG520 in a couple different ways. He was a Cisco engineer and did not have a Juniper back-ground. The tunnels do not appear to be built in a consistent manner.

The nat-traversal and cert peer-ca-hash were not necessary. I recently built the "naperville" VPN.

These questions have come up as I prepare to migrate the SSG-520 to a SRX-650.

Tunnel.1 is a concern. There are only three components to this tunnel.

set interface "tunnel.1" zone "GUIIN"

set interface tunnel.1 ip 192.xxx.54.1/30

set interface tunnel.1 tunnel encap gre

set interface tunnel.1 tunnel local-if ethernet0/0 dst-ip 121.xxx.112.74

set interface tunnel.1 tunnel keep-alive interval 10 threshold 3set route 10.21.0.0/16 interface tunnel.1

Tunnel.4 is similar but the VPN has IKE and IPSEC statements.

set interface "tunnel.4" zone "OLIUS"

set interface tunnel.4 ip 192.xxx.54.5/30

set interface tunnel.4 tunnel encap gre

set interface tunnel.4 tunnel local-if ethernet0/0 dst-ip 12.xxx.240.200

set interface tunnel.4 tunnel keep-alive interval 10 threshold 3

set ike gateway "toOlLIUS-GW" address 12.xxx.240.200 Main outgoing-interface "ethernet0/0" preshare "gXJ19Rp5NznwlQsRt5CupLuUtLniMlo5Aw==" proposal "pre-g2-3des-sha"

set ike gateway "toOlLIUS-GW" nat-traversal

set ike gateway "toOlLIUS-GW" nat-traversal udp-checksum

set ike gateway "toOlLIUS-GW" nat-traversal keepalive-frequency 0

set vpn "toOLIUS-VPN" gateway "toOlLIUS-GW" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"

set vpn "toOLIUS-VPN" monitor optimized rekey

HOWEVER… it is not bound to the tunnel interface.

I have no problem migrating VPN tunnels built on the standard VPN template.
I’m simply not sure what to do with these two. Do I rebuild them with the standard JUNOS VPN template or is there another method I should use?

Thank you in advance,

Brent

Attachment(s)

TUKWILA_VPNs.txt   3 KB 1 version

There are two kinds of IP Sec VPN: Route based and Policy based.

For Route based IP Sec VPN, you need o bind it to a tunnel interface, while for Policy based IP Sec VPN, it doesn't use tunnel interface.

Hi Brent,

Both tunnel.1 and tunnel.4 are GRE Tunnels, not IPSEC, so the configuration for the first one on your SRX will look like:

set interfaces gr-1/0/0 unit 1 tunnel destination 121.xxx.112.74

set interfaces gr-1/0/0 unit 1 family inet address 192.xxx.54.1/30

set routing-options static route 10.21.0.0/16 next-hop ge-1/0/0.1

The second one looks like it should be an IPSEC over GRE tunnel, but without the binding statement, this won't work.

Check your security policies - if you have one that references this "vpn toOLIUS-VPN" then you have a policy-based VPN which you will need to rebuild on the SRX.

Also check if there are any routes with a next-hop of tunnel.4 - it may not be being used.

Hope this helps

There is no route with a next hop of tunnel 4.

There is a policy that uses the tunnel:

set policy id 309 from "Untrust" to "corp"  "10.12.0.0/16" "172.20.6.0/24" "ANY" tunnel vpn "toOLIUS-VPN" id 0x4 log
set policy id 309
exit

So it appears to be a policy based VPN.

The other side of this tunnel is set up the same way:

set interface "tunnel.1" zone "TUKUS"set interface tunnel.1 ip 192.168.54.6/30

set interface tunnel.1 tunnel encap gre
set interface tunnel.1 tunnel local-if ethernet0/0 dst-ip 208.90.118.1
set interface tunnel.1 tunnel keep-alive interval 10 threshold 3

set ike gateway "toTUKUS-GW" address 208.90.118.1 Main outgoing-interface "ethernet0/0" preshare "gXJ19Rp5NznwlQsRt5CupLuUtLniMlo5Aw==" proposal "pre-g2-3des-sha"

set vpn "toTUKUS-VPN" gateway "toTUKUS-GW" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set vpn "toTUKUS-VPN" monitor optimized rekey

set policy id 15 from "Trust" to "Untrust"  "10.12.0.0/16" "172.20.6.0/24" "ANY" tunnel vpn "toTUKUS-VPN" id 11 pair-policy 14 log
set policy id 15
exit
set policy id 14 from "Untrust" to "Trust"  "172.20.6.0/24" "10.12.0.0/16" "ANY" tunnel vpn "toTUKUS-VPN" id 11 pair-policy 15 log
set policy id 14
exit

No route using tunnel 1 in this config either.

How much of the VPN's need to be rebuilt? Is there work that will need to be done on both sides, or will only the pre-share key need to be changed on the remote side of the VPN?

Thank you for your help. Your answer has already given enough to get started. My predecessor could have used route-based VPN's for all our remote sites. It would have made this a little less confusing, but then it wouldn't be a good learning experience 🙂

Brent

Hi dfex,

I had left part of the config out of my first post for the gre VPN (tunnel.1). You had described the SRX config as:

set interfaces gr-1/0/0 unit 1 tunnel destination 121.xxx.112.74

set interfaces gr-1/0/0 unit 1 family inet address 192.xxx.54.1/30

set routing-options static route 10.21.0.0/16 next-hop ge-1/0/0.1

Thank you!

The whole config is:

set interface "tunnel.1" zone "GUIIN"

set interface tunnel.1 ip 192.168.54.1/30
set interface tunnel.1 tunnel encap gre
set interface tunnel.1 tunnel local-if ethernet0/0 dst-ip 121.243.112.74
set interface tunnel.1 tunnel keep-alive interval 10 threshold 3

set policy id 157 from "corp" to "GUIIN"  "172.20.6.0/24" "10.21.0.0/16" "ANY" permit
set policy id 157
exit

set policy id 175 name "GUIEX01 access to CORPEX01" from "GUIIN" to "corp"  "10.21.0.0/16" "172.20.6.0/24" "ANY" permit log
set policy id 175
set log session-init
exit

set route 10.21.0.0/16 interface tunnel.1

In a normal policy based VPN the policy would point to a VPN tunnel instead of the "permit" statement. This configuration works, but does not seem to follow the rules for a normal policy based VPN. I am now just looking for some explanation of how and why they are setup this way.

I've done considerable research in the KB. I plan to engage JTAC to support my migration.

Thank you in advance,

Brent

Hi Brent,

There will probably be a route in your configuration pointing down the GRE tunnel - something like:

172.20.6.0/24 next-hop 192.xxx.54.2

The GRE tunnel behaves exactly like a point to point link.

As to why they are set up this way, it's hard to say - your colleague may have just copied an existing Cisco to Juniper tunnel configuration from somewhere else, but I'd guess it has a lot to do with Cisco / Juniper interoperability.

In IOS you don't "route" traffic down a VPN tunnel, you match a crypto-map ACL (essentially the same as policy-based VPN in ScreenOS/Junos).  IOS then uses the ACL you configure as a proxy-id when establishing the VPN tunnel.  If you have configured multiple subnets at both ends in your ACL, IOS will automatically generate multiple proxy-ids.

In ScreenOS/Junos on the other hand, regardless of whether you configure route-based or policy-based VPNs, the proxy-id will always be set to wildcard 0.0.0.0/0.  The wildcard proxy-id isn't recognised by IOS and needs to be manually configured on the Junos side to match whatever IOS is expecting (as per the crypto-map).

The next issue is that Junos/ScreenOS doesn't support multiple proxy-ids in a single VPN configuration, so if you have non-contiguous subnets on either end that don't summarise well, you will run into issues.

One way to address both of these issues is to use GRE over IPSEC.  This essentially brings route-based VPN to IOS to avoid all these issues.

First you create an IPSEC tunnel with a crypto map/proxy-id that ONLY matches the source and destination IP address of the GRE tunnel (eg: the external IPs of both of your firewalls) and the application GRE.

Then you create a GRE tunnel as normal.

Now any subnets that you wish to route between sites you point at the GRE tunnel.  This way your traffic is wrapped in GRE, and only the GRE traffic enters the IPSEC tunnel (which only allows traffic sourced or destined for your firewall interface IPs)

In your case though, it looks like you're only using the GRE tunnels, with no outer layer of IPSEC.

Hope this helps