Drop Code: 448 (SA not found on lookup by SPI for outbound pkt), Module ID: 20 (ipSec)
Tytec
Newbie ✭
All,
I have a site to site ipSec tunnel configured with a NSa 4650 on the near end and a Cisco RV340 appliance on the far end which is working as expected. When a user connects with a SSL-VPN to our NSa 4650 he isn't able to access the far end (Cisco RV340) and is getting the following error. I've checked to make sure the remote & local networks are in place as well as any access policies would permit that traffic as well as SSLVPN client routes. Has anyone else ever ran across this and what did you find to be the root cause of the problem?
Thanks for your time!
Category: Mid Range Firewalls
0
Answers
@Tytec does your Local Network definition in the IPsec tunnel holds all networks in a group which need to be routed into the Tunnel? E.g. LAN and SSLVPN Subnet?
On the Cisco side, is the Cisco aware of all Remote networks, e.g. LAN and SSLVPN Subnet on NSa?
If there is no SA negotiated it won't work.
--Michael@BWC
Thanks BWC. Yes to answer your questions. The far end is configured and aware of the SSLVPN networks.
@Tytec and the NSa? You're using an Address Group object as Local Network in the Tunnel configuration which holds all needed networks?
--Michael@BWC
Correct
Does the subnet mask match on both sides for the SSLVPN subnet which is used in the Tunnel definition?
Does the "Currently Active VPN Tunnels" section on the NSa shows only a single Active Tunnel for your VPN Connection to the Cisco or multiple?
Anything logged on the Cisco which might be helpful here?
--Michael@BWC
yes sir, on the NSa is a 255.255.255.128 and on the Cisco is a /25.
From Cisco end:
@Tytec well, this screenshot shows everything and nothing ... please check what the negotiated SAs are, I believe the SSLVPN is missing here. Check the log on the Cisco side as well.
Are you aware of any problems that the smallest negotiable size could be /24? I've seen this in the past, but this might not apply here.
Maybe some other user with more Cisco knowledge likes to chime in.
--Michael@BWC
It has negotiated SAs but for security I didn't show them in the snip. Sorry for not saying that prior.
It could be possible but I don't see any errors. I would need to make a change after hours on both units to that that.
Double checked in both NSa and RV340 logs and don't see anything related to the IPSec tunnel or SAs
On the SA(s) that contain(s) your SSLVPN subnet, do you see TX/RX bytes accumulating?
@Arkwright , I see zero traffic ingress(WAN IPSec tunnel) on the NSa to the SSLVPN subnet from the RV340. When I generate traffic sourced from the SSLVPN network, I get the following error on the NSa. I've found that RV340 has very limited visibility and functionality in terms of troubleshooting.
Thanks,
Thanks everyone for your feedback! Decided to reboot the far end (RV340) as a last resort. Post reboot traffic is passing as it should. I can't explain this anomaly but have to believe a service, process, or similar was hosed in the RV340.
@Tytec "Reboot tut gut" ... old german saying 🤓
--Michael@BWC
@BWC 😋