AnsweredAssumed Answered

Interesting traffic.. a parameter for Phase-2 negotiation?

Question asked by Ranjithkumar Pannir Selvam on Oct 22, 2018
Latest reply on Oct 29, 2018 by Kenny Manrique

hi,

 

i had a serious discussion with some technical folks regarding the Site-to-Site VPN parameter. and the scenario was, a new site to Site VPN tunnel is implemented between Site-A and Site-B. if the interesting traffic is not matching, whether the tunnel will be up?

 

i agree with the point that Phase 2 will not come up without successful Phase-1. We have encryption, Hash, PFS etc as parameter for Phase-2 negotiation. whether interesting traffic is a parameter for Phase-2 negotiation?

 

The reason for this question: interesting traffic configured in firewall-1 and firewall-2 are not identical, whether tunnel will be up with no tx/rx? or tunnel will not come-up since interesting traffic configured in both firewall is not matching.

 

RFC states this:

 

https://tools.ietf.org/html/rfc2409#section-5.5

 

The identities of the SAs negotiated in Quick Mode are implicitly    assumed to be the IP addresses of the ISAKMP peers, without any    implied constraints on the protocol or port numbers allowed, unless    client identifiers are specified in Quick Mode.  If ISAKMP is acting    as a client negotiator on behalf of another party, the identities of    the parties MUST be passed as IDci and then IDcr.  Local policy will    dictate whether the proposals are acceptable for the identities    specified.  If the client identities are not acceptable to the Quick    Mode responder (due to policy or other reasons), a Notify payload    with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.

 

How the IPSEC architecture is deployed in Checkpoint VPN?

 

thanks in advance.

Outcomes