IPSec - Interoperability with 3rd party devices

[Peter]

Hi All

I would like to discuss "Interoperability with 3rd party devices" topic of exam chart. What are possible tasks, any ideas?

Official classes seem to consider only one case, when you need OSPF-over-GRE-over-IPSec instead of just OSPF-over-IPSec with a 3rd party vendor.

Also Auto NHTB will not work with other vendor, so you will need it statically configured.

Any other ideas / gotchas / possible scenarios?

Thanks for cooperation,

Peter

[dark_15]

• Proxy ID's for tunnels when Juniper is using route-based VPN
• TCP MSS for Netscreen/Cisco (1350 bytes)
• Default Life Times and Life Size on P1/P2 Proposal
• Interoperability for Cisco GET VPN
• Dead Peer Detection
• VPN Monitoring (Optimized ICMP vs Standard)

[Peter]

Hm... Its good that I asked... You haven't given much details so I will post my understanding

of the topics, and please correct if I'm wrong.

• Proxy ID's for tunnels when Juniper is using route-based VPN

That's clear, proxy IDs must "match" on both sides. Route based uses all zero by default, policy based takes proxy ID from policy. In both cases you can override them manually.

• TCP MSS for Netscreen/Cisco (1350 bytes)

Not clear for me how it relates to vendor interoperability. Setting TCP MSS on tunnel just allows you to evade excessive fragmentation, right?

 

• Default Life Times and Life Size on P1/P2 Proposal

This could be the problem, right. Some vendors require that configured lifetimes match on both sides. If VPN is SRX-SRX, this is not required (I tested it).

• Interoperability for Cisco GET VPN

This one is not on exam chart, so I really hope they will not do it to us :) 

• Dead Peer Detection

 This is standard, and by the way RFC states that DPD intervals don't have to match on both sides.

• VPN Monitoring (Optimized ICMP vs Standard)

This is Juniper's propritary version of track IP for VPN, so that SRX can be configured to probe ip through the tunnel. Should work with other vendors' equipment on other end.

Thanks,

Peter

[dark_15]

On Saturday, August 4, 2012 1:14:27 PM UTC-4, Peter wrote:

Hm... Its good that I asked... You haven't given much details so I will post my understanding

of the topics, and please correct if I'm wrong.

• Proxy ID's for tunnels when Juniper is using route-based VPN

That's clear, proxy IDs must "match" on both sides. Route based uses all zero by default, policy based takes proxy ID from policy. In both cases you can override them manually.

 You hit the nail on the head. Thx for clarifying it can be done on Policy-Based VPN's

• TCP MSS for Netscreen/Cisco (1350 bytes)

Not clear for me how it relates to vendor interoperability. Setting TCP MSS on tunnel just allows you to evade excessive fragmentation, right?

Not entirely. This is more of personal experience where traffic was dropped due to a MSS mismatch or the tunnel bouncing due to the peers not being able to reassemble the fragments (poor Cisco PIX!). SRX's by default don't have/need MSS set since it usually negotiated with the TCP handshake. ScreenOS, Cisco, Checkpoint, etc. may not always always handle the negotiation correctly, and instead force a static MSS for VPN traffic.

Application Note (Page 8)

 

• Default Life Times and Life Size on P1/P2 Proposal

This could be the problem, right. Some vendors require that configured lifetimes match on both sides. If VPN is SRX-SRX, this is not required (I tested it).

It is generally good practice to make sure the lifetimes on P1/P2 match. In SRX/ScreenOS the standard P1 lifetime for their proposal-set is set to 28800 seconds (8hr), and in P2 it is 3600 seconds. On Cisco it's 86400 seconds for P1, and 28800 seconds for P2. With mismatched lifetimes one side could bring down the tunnel and be unable to re-negotiate because the other peer still thinks the tunnel is up.

• Interoperability for Cisco GET VPN

This one is not on exam chart, so I really hope they will not do it to us :) 

I hope not either, but Group VPN is. Just in case I'm reading this and hoping for the best: 

Link: http://www-jnet.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/index.html?topic-53319.html

 

• Dead Peer Detection

 This is standard, and by the way RFC states that DPD intervals don't have to match on both sides.

Agreed, but it is important to differentiate what DPD does versus VPN monitoring. Also it's important to note how DPD behaves on 10.4R2 and earlier versus 10.4R3 and 11.1

Links: KB21652

• VPN Monitoring (Optimized ICMP vs Standard)

This is Juniper's propritary version of track IP for VPN, so that SRX can be configured to probe ip through the tunnel. Should work with other vendors' equipment on other end.

I don't disagree, and maybe this is more of an operational/troubleshooting issue versus interoperability issue. In many cases the remote peer will not allow the ICMP traffic between the VPN peers. When the SRX cannot ping across the tunnel, it will bring the VPN down even though traffic flowing through it is working as expected. You work around this by setting source interface and destination IP to test monitoring with, or by using the optimized option. Optimized allows you to use traffic flows in place of the ICMP pings to determine if the tunnel is up. In the event there are no flows then the SRX will start sending ICMP to ensure the tunnel is up.

Links: KB10119, KB10118

Thanks,

Peter

- Clay 

[Peter]

Hi Clay,

Thanks for your comments and links. But why do you say that Group VPN is an exam topic? I can't see it here 

https://www.juniper.net/us/en/training/certification/resources_jnciesec.html#04 

Thanks,

Peter

[dark_15]

Mostly because of the interoperability piece with 3rd party devices. Group/GET VPN Interoperability has its own section inside the release notes so I would not be surprised if it was not on their one way or another.

[Yorick]

> That's clear, proxy IDs must "match" on both sides. Route based uses all zero by default, policy based takes proxy ID from policy. In both cases you can override them manually.

Okay, now consider this scenario: SRX on one side, ASA on the other. For added fun, have 3 subnets each side.

ASA can only do policy-based. It's also really picky about traffic matching the proxy-id. That means you have to have 9 (3 x 3 for all possible combinations) different proxy-ids configured. You can go about this two ways:

- Policy-based VPN. You will need 9 policies, as otherwise the proxy-id becomes all zeros again when there is more than one address object. This will work - in the absence of NAT. Ways this will break:
  o You need NAT through the tunnel. No can do. Look at the flow diagram to understand why - the issue is with the order of NAT and policy lookup
  o You have a static NAT for one of the hosts traversing the tunnel. That is, your intent is to static NAT it to the Internet, but not through the tunnel. This will break. Destination-NAT on the Internet side may be a way around this.

- Route-based VPN. You will need to use NHTB, with "dummy" tunnel addresses on the Cisco side. Because you have three source subnets, you'll also need to use FBF. You'll again end up with 9 proxy-ids, and the accompanying FBF and NHTB entries for them. It's a labor-intensive thing to set up.
  o Much more work to set up than policy-based VPN
  o Will continue working no matter what you do with NAT elsewhere, and can NAT traffic through the tunnel, too

Route-based is the way to go, IMO. If you can keep the SRX-side subnet to just one network, you save yourself FBF and a whole lot of headache.

What I'd love is a way to have multiple proxy-ids for a route-based VPN, similar to what ScreenOS 6.3 introduced. That would solve this interop problem.

CheckPoint interop, btw: Choose "only one tunnel per VPN" (instead of "one tunnel per subnet", which is the default), and it'll use an all-zero proxy-id and work just fine with an SRX.

[Red1]

Hi Peter 

FYI, for GRE over IPSec , this solution is not supported on SRX chassis cluster mode in Junos 11.4, please check the link below note: 

• On all branch SRX Series devices, sessions going through GRE over IPsec are not marked as backup on backup node, instead, they are marked as active on backup node. This behavior causes the real active session to be deleted. Nesting tunnel, like GRE over IPsec, is not supported on chassis cluster.

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/release-notes/11.4/index.html?topic-62169.html 

Regards