ipsec proposal

[suthomas1]

Goodday everyone,

In one of the ipsec vpn, both phase1 and phase2 configuration show "set proposal "aes256-sha1 aes256-md5".

what is the need for two authentication & encryption methods for a single ipsec connection and how will this work?

[emnoc]

The short answer, phase1, and phase2 are negotiated separately. You can use different encryption and with forward secrecy, you can negotiate pahse2  with keying material that is not derived from phase1.

Ken Felix

[suthomas1]

thank you, more specifically what does set proposal aes256-sha1 aes256-md5 under phase1 interface mean?

i am new to ipsec, so will appreciate to gain some understanding on it.

[ede_pfau · Accepted solution]

Some explanation of the IPsec proposal negotiation:

Both sides, the initiator and the responder, maintain lists of proposals they support. In phase1 and again in phase2, the initiator proposes it's supported algorithms to the responder in the priority listed - e.g., aes256-sha1 first. If the responder supports this proposal, both sides agree on this and terminate the negotiation. If not, the next proposal (with lower priority) is offered from the initiator, and so on, until either a match is found or the list is depleted. In the latter case, the connection attempt fails.

You'll find numerous sources on the net, for example here (https://www.networkworld.com/article/2288666/chapter-4--common-ipsec-vpn-issues.html)

So, in short terms:

- the initiator needs to offer at least one proposal for encryption/hashing algorithms

- multiple proposals are offered in sequence, highest desireable proposal first

- as soon as one proposal is matched by the responder, the negotiation succeedes and both sides continue with the next step

- if even the last proposal is unmatched, the negotiation fails and the connection attempt is broken off

In practice, if you control both sides of an site-to-site IPsec VPN, you propose the same algorithms on both sides, so that the very first proposal is chosen. In this case, there is no need to offer multiple proposals.

If you do not control the responder side, offer a (small) number of acceptable algorithms, most desireable first. IMHO you should not include MD5, DES or 3DES algorithms as they have been compromised in the past.

If you only control the responder side, offer a list of decent proposals, only to include the weakest acceptable at the end. Usually, the operator of the VPN gateway will communicate the desired / accepted proposals in advance (but he doesn't have to, as that's what the negotiations are there for).

One more: in FortiOS, not all available algorithms are supported by the NP ASIC, i.e. can be offloaded. This depends highly on the hardware used. If not supported for offloading, algorithms will still work but are processed by the CPU (in software) which might limit the throughput drastically.

[suthomas1]

Thanks Ede.

So can both phase1&2 use same proposal , set proposal aes256-sha256 ?

what is the difference between keylifeseconds in phase 1&2. should they be the same?

[ede_pfau]

You can use identical proposals on phase1 and phase2. But you don't have to. I usually do.

Just make 100% sure proposals match on both gateways.

Phase1 and phase2 both create keys which expire over time, and usually are re-created automatically. Both settings are independent of each other.

I usually set phase1 lifetime to 28800 sec, and phase2 lifetime to 1800 sec. Check 'Auto-negotiate' and 'Autokey Keep Alive' in phase2. The auto-negotiation for phase1 is enabled by default.