Sonic wall dropped packet from only 1 host
While trying to configure an IP timeclock at a remote location of which we have a VPN between 2 sonic walls. Local is NSA200 and remote is a z105.
Everything is and has been working until I notice that the server which holds our new payroll system cannot get to the remote LAN. After numerous tests, I had to look at the packet and found this
DROPPED, Drop Code: 191(SA not found on lookup by SPI for outbound pkt), Module Id: 20(ipSec),
I've opened a support case with dell but the 4-6 hours that I was supposed to hear back was over about 24 hours ago. Before I call on Monday I thought I would set it up here to make sure someone hasn't seen it before.
I've found this error on the knowledgebase but it didn't really offer a solution, only verified that this is in fact an error.
Perhaps if I knew for sure what the acronyms meant I could know where to look. SPI would be stateful packet inspection I assume and SA is ? Source Address?
Anyway, looking for any tips.
Everything is and has been working until I notice that the server which holds our new payroll system cannot get to the remote LAN. After numerous tests, I had to look at the packet and found this
DROPPED, Drop Code: 191(SA not found on lookup by SPI for outbound pkt), Module Id: 20(ipSec),
I've opened a support case with dell but the 4-6 hours that I was supposed to hear back was over about 24 hours ago. Before I call on Monday I thought I would set it up here to make sure someone hasn't seen it before.
I've found this error on the knowledgebase but it didn't really offer a solution, only verified that this is in fact an error.
Perhaps if I knew for sure what the acronyms meant I could know where to look. SPI would be stateful packet inspection I assume and SA is ? Source Address?
Anyway, looking for any tips.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I double checked, the Tunnel was for the entire subnet and even thought to assign a static address one above and one below the IP in question to test. Everything tested ok.
The comments and my test lead me to believe that there isn't an issue with the VPN or the firewall, rather perhaps the NIC or config on the server. There is a second NIC in the server used for some legacy PCs to files hare on a different LAN. Even though the sniffer shows the correct LAN address source 192.168.110.99, it must have been trying to use the 10.10.10.250 that I had setup for this net.
I disabled the second NIC and everything is working as expected. So I guess the issue is setting NIC 1 as primary. Or just move the file share to another box. Which shouldn't be too hard to do. Thanks for helping me work through things.
The comments and my test lead me to believe that there isn't an issue with the VPN or the firewall, rather perhaps the NIC or config on the server. There is a second NIC in the server used for some legacy PCs to files hare on a different LAN. Even though the sniffer shows the correct LAN address source 192.168.110.99, it must have been trying to use the 10.10.10.250 that I had setup for this net.
I disabled the second NIC and everything is working as expected. So I guess the issue is setting NIC 1 as primary. Or just move the file share to another box. Which shouldn't be too hard to do. Thanks for helping me work through things.
there is a VPN tunnel exchanges that failed from local to remote.
in fact, normally for such drop code message, I tend to see mostly due to failure in SA (security association) exchanges between local and remote end causes due to changes of FW blocking new IP addresses access.. and also any recent upgrade or refresh done on the two ends or routing changes, that will need to be verified VPN is alright for other host using the existing remote services. The zone for the routing needed to be apply with the VPN policy too (esp your remote site).
there is one instance for traffic bound for remote behind a SonicWALL TZ 190W is dropped at the NSA appliance https://support.software.dell.com/kb/sw5849
Just side note on below pertaining to the term used in error msg
> SA is Security Association that depict rules that the end to end tunnel going to set up in accordance to this set of rules
> SPI is Security Parameter Index that is an ID added to the header used in IPsec tunnel traffic. Kinda of "ID" for different set of SA when each end talks to each other
in fact, normally for such drop code message, I tend to see mostly due to failure in SA (security association) exchanges between local and remote end causes due to changes of FW blocking new IP addresses access.. and also any recent upgrade or refresh done on the two ends or routing changes, that will need to be verified VPN is alright for other host using the existing remote services. The zone for the routing needed to be apply with the VPN policy too (esp your remote site).
there is one instance for traffic bound for remote behind a SonicWALL TZ 190W is dropped at the NSA appliance https://support.software.dell.com/kb/sw5849
Just side note on below pertaining to the term used in error msg
> SA is Security Association that depict rules that the end to end tunnel going to set up in accordance to this set of rules
> SPI is Security Parameter Index that is an ID added to the header used in IPsec tunnel traffic. Kinda of "ID" for different set of SA when each end talks to each other
Seems like it is terminal end not routing to the VPN zone then...
Somewhere that host, or the host it is trying to connect to, says it must go through the VPN tunnel you have created. One end of the VPN tunnel is not configured to allow one of the two host sthrough the tunnel.
My guess is that one of the two hosts is not in the same subnet as all other hosts that are using that tunnel.