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

[Ranjithkumar_Pa]

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.

[PhoneBoy]

I'm not sure exactly what you mean by "interesting traffic."

That said, the actual ports and protocols allowed per policy can be specified as part of the Phase 1/2 negotiation, at least as far as the various IPSec RFCs are concerned.

Check Point gateways always assume this is "any" regardless of the actual policy configured.

This did create a compatibility issue with the Nokia CryptoCluster gateways back in the day.

The upshot of this is that the security policy on both sides need not match.

That said, a tunnel will only be "up" so long as traffic traverses the tunnel.

If there is no traffic for an extended period of time, then there will be no tunnel.

[JozkoMrkvicka]

If you want to have tunnel always up even without any real traffic, use Permanent Tunnel.

[KennyManrique]

In short: If the interesting traffic does not match, the tunnel Phase 2 will not go to up state.

On Phase 2 all the host - network/mask pairs are exchanged and must be a mirror on both ends:

If GWA proposes 192.168.1.0/24 (local domain) - 192.168.2.0/24(remote domain); GWB should propose 192.168.2.0/24 (local domain) - 192.168.1.0/24 (remote domain). However, there are special cases where this rule is not followed, especially if you are trying to build tunnels between same vendor who maintain propietary checks for this (view supperneting on Check Point) or if you use VTI and encrypt according to routing table (on this case you negotiate a tunnel between gateways instead hosts or networks, using a universal tunnel 0.0.0.0/0).

That's why the description on Phase 2 is the following, denoting that the GW receiving the non acceptable interesting traffic should respond that the negotiation is invalid:

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.

Regards.