Why some IKEv2 negotiation failing due to DH group?

• PaloAlto Firewalls 
• Supported PAN-OS
• IPSec VPN

1. Peer is configured with multiple DH groups.
2. Local Firewall is configured with Just one DH Group.
3. Here during negotiation each group is tried one at a time till the match is found.
4. The non matching groups fail negotiation.
5. The working can be explained in the following way. These are not logs.

Peer: SA_INIT - I can do either of DH 21, 14, 15. let's try DH 21 first
                   PanOS: sorry, DH 21 is invalid to me, but I accept DH 14
Peer: SA_INIT - I can do either of DH 21, 14, 15. let's try DH 21 first
                   PanOS: sorry, DH 21 is invalid to me, but I accept DH 14
Peer: SA_INIT - I can do either of DH 21, 14, 15. let's try DH 21 first
                   PanOS: sorry, DH 21 is invalid to me, but I accept DH 14
...
180 seconds later
...
Peer: OK, OK, let's try DH 14
                  PanOS: DH 14 works

6. This information can be seen in ikemgr logs (less mp-log ikemgr.log) as follows.

+0100  [DEBG]: {   15:     }: see whether there's matching transform
+0100  [DEBG]: {   15:     }: found same ID. compare attributes
+0100  [DEBG]: {   15:     }: OK; advance to next of my transform type
+0100  [DEBG]: {   15:     }: see whether there's matching transform
+0100  [DEBG]: {   15:     }: transform ID doesn't match: my DH14[14], peer DH21[21], skip to next ...
+0100  [DEBG]: {   15:     }: transform ID doesn't match: my DH14[14], peer DH20[20], skip to next ...
+0100  [DEBG]: {   15:     }: transform ID doesn't match: my DH14[14], peer MODP3072[15], skip to next ...
+0100  [DEBG]: {   15:     }: found same ID. compare attributes
+0100  [DEBG]: {   15:     }: OK; advance to next of my transform type
+0100  [DEBG]: {   15:     }: success

https://datatracker.ietf.org/doc/html/rfc7296#page-35

RFC7296

If_ the initiator guesses wrong_, the responder will respond with a Notify payload
of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the 
initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. The 
initiator MUST again propose its full set of acceptable cryptographic suites because 
the rejection message was unauthenticated and otherwise an active attacker could 
trick the endpoints into negotiating a weaker suite than a stronger one that they both prefer