Stange errors on TZ170 with unknown LAN subnet 1

[PaganGod]

We are having a strange error logged on the SonicWall TZ170 we use at our main office. We have a remote office which uses a SonicWall TZ150. We use the TZ series devices to protect traffic between the sites via IPSec tunnels. Both devices seem to indicate that the tunnels are established without issue, and we can get traffic over the VPN without any problems. However, we have noticed the following errors repeating several times an hour. They are only logged on the TZ170 unit. The errors are as follows:

01/09/2006 19:22:28.464 IKE Responder: IPSec proposal does not match (Phase 2) <Remote_WAN_IP>, <Remote_WAN_IP>.skyriver.net <Main_WAN_IP>, <Main_WAN_IP>.orange.nextweb.net 192.168.123.77/32 -> 192.168.100.0/24

01/09/2006 19:22:28.464 IKE Responder: No match for proposed remote network address <Remote_WAN_IP>, <Remote_WAN_IP>.skyriver.net <Main_WAN_IP>, <Main_WAN_IP>.orange.nextweb.net 192.168.123.77/32

What is interesting is that 192.168.100.0/24 is the correct subnet for the main office (where the TZ170 is located) but the other LAN subnet identified in the first log message above (192.168.123.77/32) is NOT actually in use ANYWHERE in our WAN. The remote office is on the 192.168.98.0/24 subnet.

Another fact of possible relevance is that at both locations, we use wireless broadband for our network connectivity. SkyRiver is a subsidiary of NextWeb, and they have said they do not know what might be causing this issue, but they claim that they do not believe it is related to their portion of the system.

We have another remote site, the CEO's home office, that uses an identical TZ150 to the one at the remote office. It also connects to the TZ170 at the main office, using a different, but very similarly configured IPSec policy. The broadband connectivity at that location is via residential cable modem via Adelphia, and we never see any errors like those above that reference the WAN IP at the CEO's house. The subnet at the CEO's home office is 192.168.99.0/24.

All of the IPSec tunnels are main mode, with endpoints identified by IP address (not DNS names) and use preshared keys. We are not using the GroupVPN capability, and in fact it is disabled on all SonicWall endpoints.

I can provide any other information requested, but mostly I am interested to see if anyone has ever seen anything like this. All TZ units are running SonicOS Standard, current firmware. Any guidance is appreciated!


Regards,

Bill

 

[SonicWALLInstructor]

Sorry noone helped you. I know it's about a month later but if you are having the same problem post it again and I will answer it. I am getting more involved in the forums and will try to help everyone I can. also if you have any other problems please post them here. I will answer them the best I can.

Roger L White CISSP, CISA, CISM, GSEC
Certified SonicWALL Instructor
Security Team
Invenio Technology
(212)244-4994 ext. 715
(917)326-0386
Need Help call anytime.

 

[PaganGod]

I actually got escalated to 3rd level support, then it got escalated to hardware engineering. It turned out the errors were being thrown because a dual-homed (two NICS on separate LAN subnets) PC running some process control software is putting packets with the source IP address of one card out on the other NIC. They were NTP packets, from god knows what (maybe the Rockwell Automation software package) and I only figured it out by using Ethereal (which rocks, by the way!) and capturing the traffic.

Anyway, even though I created rules to drop all packets with the "rouge" source IP, and even though it is an invalid IP for that interface of the TZ170, it was being passed by the Standard OS because it had a destination IP that was on a valid subnet (at the other end of a VPN tunnel) so they are claiming it is not a bug, but a "limitation of the Sonic Standard OS" which sounds kinda like an "errata" on hardware issues. At least I know where it is coming from now, so I will not worry about it too much. Thank you for your offer of assistance.

 

[SonicWALLInstructor]

I'm glad you fixed the problem, it sounds like of of those sleepness nights - blow my weekend - kind of problem.

I work closely with the engineers and QA, can you tell me which one you worked with???

By the way I love Ethereal too. (That sounds geeky)

Roger L White CISSP, CISA, CISM, GSEC
Certified SonicWALL Instructor
Security Team
Invenio Technology
(212)244-4994 ext. 715
(917)326-0386
Need Help call anytime.

 

[PaganGod]

The last guy who helped on this issue (3rd level, AKA non-outsourced support) was Adam H. I do not know who it was escalated to in Engineering. I will keep you in mind next time I run up against something vexing with a SonicWall. I sell them into most of my clients (any who want to work remotely with any security) although for a basic IPSec endpoint, with limited tunnels, I have had good sucess with the older FVS-318s from Netgear. Thanks again for your offer of assistance.!

 

[SonicWALLInstructor]

OK Cool, thanks for the name. I will talk to Adam next week when I head back to Sunnyvale (SonicWALL's HQ)to worship at the Silcon Valley Tech Altar to sacifice a PC.

Yea the Netgear FVS series (Basic Blue Box) is a very good box for small clients, however the hardware resources are low so it can only support at top performance about 5 users internally and 3-5 VPN users. Look at the TZ150 for better power and performance.

Roger L White CISSP, CISA, CISM, GSEC
Certified SonicWALL Instructor
Security Team
Invenio Technology
(212)244-4994 ext. 715
(917)326-0386
Need Help call anytime.