Skip to main content
suthomas1
suthomas1
New Member
June 22, 2020
Solved

ipsec proposal

  • June 22, 2020
  • 1 reply
  • 9796 views

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?

 

 

 

Best answer by ede_pfau

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.

1 reply

emnoc
emnoc
New Member
June 22, 2020

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
suthomas1Author
New Member
June 22, 2020

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
SuperUser
ede_pfauAnswer
SuperUser
June 22, 2020

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.

Terms & ConditionsAccessibility statement