"Packet is dropped because there is no valid SA" after Management Server upgrade

[Exonix]

Hi everyone,

We had following infrastructure:

- one management server R77.30
- one security gateway R77.20

Recently we upgraded management server to R80.40 and after that all VPNs with 3rd party peers have got a problem even if VPN is established:

"Packet is dropped because there is no valid SA - please refer to solution sk19423 in SecureKnowledge Database for more information"

What we tried:

- dissabled suppernetting for a community (changed the ike_p2_enable_supernet_from_R80.20 parameter from "by_global" to "false")

- reset SA for a peer (#vpn tu, 7 Peer-IP)

both didn't help.

How can we fix this issue?

Thank you in advance!

[Timothy_Hall]

That "packet is dropped as their is no valid SA" message is just a symptom of your problem, not the actual problem.  Look at the other VPN logs surrounding this message, you should see the actual cause such as "no proposal chosen", "no response from peer" or something like that.

It is likely that you had some manual per-peer VPN domain definitions in the $FWDIR/conf/user.def.FW1 file on your old R77.30 SMS that did not survive the upgrade; these are common with third-party VPN peers such as Sonicwall/Fortinet/Juniper which are extremely picky about what Phase 2 subnets/Proxy-IDs they will accept.  See Scenario 1 of sk108600: VPN Site-to-Site with 3rd party.  Note that the user.def* file name has changed in R80.40, and the customized contents of the original $FWDIR/conf/user.def.FW1 file must be placed in the $FWDIR/conf/user.def.R77CMP file on your R80.40 SMS to work properly.  See sk98239 - Location of 'user.def' files on Security Management Server

[Exonix]

Hi @Timothy_Hall ,

currently we use "One VPN tunnel per subnet pair" that means Encryption Domain is defined manually like before upgrade. And it wasn't in-place upgrade, but migtration to another host.

The solution that you gave, I have already tried: changed the ike_p2_enable_supernet_from_R80.20 parameter from "by_global" to "false". I've opened GuiDBedit and this change is still present. And now I have an interesting thing:
- we did migration 10th Aug.
- we changed "ike_p2_enable_supernet_from_R80.20" 12th Aug
- but I see, that user.def.FW1 still has last modified date 10th Aug, and user.def.R77CMP even Jan. 2020.

Any ideas?

[the_rock]

Timothy Hall is correct...it definitely could be the fact that some of those files have changed on the mgmt server. So you are saying all if your tunnels are showing same thing? 

[Exonix]

Hi @the_rock , no, only three VPNs have this issue. Other 10+ work as before.

We didn't perform in-place upgrade, but migrated MNGT to another server. Let's see if I can get old file and compare them.

[the_rock]

Right, I see what you mean. Hm, if only 3 are broken, thats even more puzzling...yea, if you have old file to compare, that would definitely help. Just curious...those 3 that fail, are they all CP to 3rd party or cloud provider or cp to cp? What about ones that do work? Any permanent tunnels?

[Exonix]

All CP to 3rd party. non-permanent, but we constantly monitore some remote hosts.

But we also have another CP to 3rd party (like Cisco) and they still work.

[the_rock]

I get it...thats why I find that very confusing. One thing I would check is vpn settings in guidbedit for say community that works and one that does not...see if you can spot any major differences.

[Timothy_Hall · Accepted solution]

Sigh please read my prior post again...

Yes the Cisco one still works because Cisco is less strict about the subnets/Proxy-IDs it will accept unlike Fortinet/Sonicwall/Juniper and doesn't need user.def* modifications to work typically.

Everything else you mentioned in your last reply (One VPN tunnel per subnet pair, ike_p2_enable_supernet_from_R80.20) is not relevant to the contents of the $FWDIR/conf/user.def.FW1 which will override all that.  Find the $FWDIR/conf/user.def.FW1 file on your original R77.30 SMS (not the upgraded R80.40 one) and I can *guarantee* you have subnet_for_range_and_peer directives in there.  Those directives need to be placed in the $FWDIR/conf/user.def.R77CMP file on your upgraded R80.40 SMS, and then reinstall policy to your gateways.  Full stop.

[the_rock]

Lets hope that works for him...fingers crossed!

[Exonix]

thank you very much. it did help.