cjdavis618
asked on
Sonicwall loses acces to specific IP that is inside an IPsec tunnel?
I have a client that uses a TZ170 at one office then has a remote office that uses terminal services for 5 users also with a TZ170 using a branch tunnel. We have printers mapped to internal ip addresses on the different subnet as the main office. office subnet is 192.168.1
x and remote is 192.168.5.x
Every few days, the VPN loses traffic to a printer that is static IP (192.168.5.193) and it will no longer print. You can ping the server from the remote location, but you can't ping from the server to the printer or any other station. But oddly, the users can still access programs and such directly without problems.
I have pulled my hair out over this problem and Sonicwall has no idea either. I have recreated the tunnel, tried logging the traffic and it just shuts down. Any ideas?
The only way to get the connection back is to reset the sonicwall and it will work for a few days.
x and remote is 192.168.5.x
Every few days, the VPN loses traffic to a printer that is static IP (192.168.5.193) and it will no longer print. You can ping the server from the remote location, but you can't ping from the server to the printer or any other station. But oddly, the users can still access programs and such directly without problems.
I have pulled my hair out over this problem and Sonicwall has no idea either. I have recreated the tunnel, tried logging the traffic and it just shuts down. Any ideas?
The only way to get the connection back is to reset the sonicwall and it will work for a few days.
ASKER
Yes, both networks use DHCP via the TZ170s at the specific office. The Printer which is at 192.168.5.193 is not excluded but it is not part of the scope. All addresses that are static have the included gateway to the firewall and the DNS address of the ISP service as well as the primary DNS set to the server for DNS resolution.
As I mentioned, I can reset the sonicwall TZ170 at the main office, then it will reconnect the tunnel and all is well for a few days. Then randomly, the IP will not be able to ping the printer and I have to reset the main office tz170 to continue. At first, I had the printer set up wireless in the office, but in trouble shooting the problem, I have moved that to wired.
I would suspect the printer is the culprit.... Except that the only thing I have to do to get connection again is reset the main office firewall. I have never reset the printer or the branch firewall.
It seems like it is blocking that particular printer as if it was an attacker or something. Logs show nothing when it occurs.
Thanks for your help.
I want to figure out if there is a problem with the firewall itself. At this point I am very leery of using that unit again. We are about to replace the TZ170 with aTZ190 and an SSL2000VPN at the main office for remote users which will give us load balancing over our slow isp lines and better "user experience" since the office is growing very rapidly.
I do not want to move the problem to a new location if it is the firewall that is problem.
As I mentioned, I can reset the sonicwall TZ170 at the main office, then it will reconnect the tunnel and all is well for a few days. Then randomly, the IP will not be able to ping the printer and I have to reset the main office tz170 to continue. At first, I had the printer set up wireless in the office, but in trouble shooting the problem, I have moved that to wired.
I would suspect the printer is the culprit.... Except that the only thing I have to do to get connection again is reset the main office firewall. I have never reset the printer or the branch firewall.
It seems like it is blocking that particular printer as if it was an attacker or something. Logs show nothing when it occurs.
Thanks for your help.
I want to figure out if there is a problem with the firewall itself. At this point I am very leery of using that unit again. We are about to replace the TZ170 with aTZ190 and an SSL2000VPN at the main office for remote users which will give us load balancing over our slow isp lines and better "user experience" since the office is growing very rapidly.
I do not want to move the problem to a new location if it is the firewall that is problem.
I'm not aware of any "bug" like this in the Sonicwall range. it seems too specific to be a "fault" in the particular unit.
If you' re contacting the printer remotely then the printer *will* count towards your user-limit (if any) on the TZ170. But if that were the issue you'd see "licence count exceeded" messages in the log.
When this particular ping route dies, can you ping the printer from anywhere else, locally or remotely? Can you ping it from the Sonicwall?
If you' re contacting the printer remotely then the printer *will* count towards your user-limit (if any) on the TZ170. But if that were the issue you'd see "licence count exceeded" messages in the log.
When this particular ping route dies, can you ping the printer from anywhere else, locally or remotely? Can you ping it from the Sonicwall?
ASKER
Good ideas there.
Both of the TZ170s are unlimited nodes. So License count isn't an issue there. It was before and the Sonicwall at the main office has been through 2 user license upgrades. I can access the printer from the remote office locally and print. I cannot ping it from either the sonicwall at the main office or behind it.
It wouldn't be a problem except they use Terminal services and the printer is mapped back from the server to the printer through the VPN tunnel using the Ip.
Along with the other upgrades, we have decided to install .RDP Print from thinprint so they can print anywhere anytime without printer mapping. So this problem would go away anyway. But like I said, the only thing I haven't done yet is reload the firmware and start over with it.
The one thing that I haven't mentioned yet is that there are 2 branch offices running from the 1 Main. We do not use TS on the other network so I can't tell if this is an isolated problem. I just find it strange that it picks one printer repeatedly to block with no rhyme or reason.
Also the TZ170 at the main is not the wireless model. The one at the branch - TZ170W. Just making sure I give all the info.
Both of the TZ170s are unlimited nodes. So License count isn't an issue there. It was before and the Sonicwall at the main office has been through 2 user license upgrades. I can access the printer from the remote office locally and print. I cannot ping it from either the sonicwall at the main office or behind it.
It wouldn't be a problem except they use Terminal services and the printer is mapped back from the server to the printer through the VPN tunnel using the Ip.
Along with the other upgrades, we have decided to install .RDP Print from thinprint so they can print anywhere anytime without printer mapping. So this problem would go away anyway. But like I said, the only thing I haven't done yet is reload the firmware and start over with it.
The one thing that I haven't mentioned yet is that there are 2 branch offices running from the 1 Main. We do not use TS on the other network so I can't tell if this is an isolated problem. I just find it strange that it picks one printer repeatedly to block with no rhyme or reason.
Also the TZ170 at the main is not the wireless model. The one at the branch - TZ170W. Just making sure I give all the info.
I don't thing TS can be the issue. Given Microsoft's prowess, it would NOT surprise me at all to find that TS cients "lost" the printer when you can still access it via IP - but if PING won't even find it, then the failure is a at much lower level than the app.
Do any other IP addresses get "lost"? Or do you not access any other Ips via the same route. It might be interseting to have something like Angry IP Scan search the *entire* remote network, both when you are getting a good connect to the printer and again when you are not, to see what else, if anything, is affected.
I hope this is a daft question BUT you ARE using DIFFERENT ip network ranges at each of the three offices?
Do any other IP addresses get "lost"? Or do you not access any other Ips via the same route. It might be interseting to have something like Angry IP Scan search the *entire* remote network, both when you are getting a good connect to the printer and again when you are not, to see what else, if anything, is affected.
I hope this is a daft question BUT you ARE using DIFFERENT ip network ranges at each of the three offices?
ASKER
Yes, each branch is a separate subnet. We are 192.168.1.x, 192.168.3.x, and 192.168.5.x
There is also a Mobile VPN user (the owner) that dials in on 192.168.2.x at times, but he doesn't use it but once every 4-5 months.
As for pinging others, as I mentioned in my question. All stations become blacklisted in the 192.168.5.x network. At that same time, all other VPN tunnels are live and active. It selectively removes this subnet from the route almost. Even though the clients from there can connect to the server, the server nor stations from the 192.168.1.x can't connect to anything at the 192.168.5.x network. We have never had this occur to the 192.168.3.x network to my knowledge.
I will try to connect from the 192.168.3.x network when it happens again.
There is also a Mobile VPN user (the owner) that dials in on 192.168.2.x at times, but he doesn't use it but once every 4-5 months.
As for pinging others, as I mentioned in my question. All stations become blacklisted in the 192.168.5.x network. At that same time, all other VPN tunnels are live and active. It selectively removes this subnet from the route almost. Even though the clients from there can connect to the server, the server nor stations from the 192.168.1.x can't connect to anything at the 192.168.5.x network. We have never had this occur to the 192.168.3.x network to my knowledge.
I will try to connect from the 192.168.3.x network when it happens again.
And the VPN tunnel still reports "up" when this happens?
Very odd.
Are the Sonicwalls all on latest firmware?
Have you asked Sonicwall online support if they know of any problem?
Got me baffled....
Very odd.
Are the Sonicwalls all on latest firmware?
Have you asked Sonicwall online support if they know of any problem?
Got me baffled....
ASKER
Yes, the tunnel still shows to be up and the traffic monitor is showing throughput.
The TZ170 they have at the main office is not on maintenance since we are upgrading it. This problem started just before it expired. I called and it was so close to the end they wanted to renew it before we got to far. I had already sold them the SSL solution anyway though and it wasn't worth spending more money on. I just thought someone might have run into this before.
I should also note that the unit is running Sonic OS standard, but no it isn't on the latest firmware.
I believe that the unit is overloaded to be honest. I read somewhere that it is really only meant for 2 tunnels max and with the bandwidth limitations we have in that city, it isn't helping any.
I think I am going to mothball that unit and make it a paperweight. It has served its purpose and I don't like questionable equipment. I don't want to pass the problem on down the line to another office when it opens.
Thanks for all your help. Unless someone else has an answer to the problem, I will award you the points for trying to help out.
The TZ170 they have at the main office is not on maintenance since we are upgrading it. This problem started just before it expired. I called and it was so close to the end they wanted to renew it before we got to far. I had already sold them the SSL solution anyway though and it wasn't worth spending more money on. I just thought someone might have run into this before.
I should also note that the unit is running Sonic OS standard, but no it isn't on the latest firmware.
I believe that the unit is overloaded to be honest. I read somewhere that it is really only meant for 2 tunnels max and with the bandwidth limitations we have in that city, it isn't helping any.
I think I am going to mothball that unit and make it a paperweight. It has served its purpose and I don't like questionable equipment. I don't want to pass the problem on down the line to another office when it opens.
Thanks for all your help. Unless someone else has an answer to the problem, I will award you the points for trying to help out.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Update on the problem.
During testing this week, I found that when the printer is not accessible, then neither are some of the other PCs on that network. Oddly though 2 of them always were. So it isn't blocking the entire subnet, just parts of it. The problem is that the stations that were allowed were intermixed with the rest of the IPs. I.E.. IPs X.21 x.24 x.27 x.28 were blocked while IPs X.22 x.26 were not. :::::more confused:::: Then after reset of the main TZ170 they come back to life.
I have replaced the unit now with the TZ190 but I will leave this open a bit longer incase that we have the same issue or other input is found.
During testing this week, I found that when the printer is not accessible, then neither are some of the other PCs on that network. Oddly though 2 of them always were. So it isn't blocking the entire subnet, just parts of it. The problem is that the stations that were allowed were intermixed with the rest of the IPs. I.E.. IPs X.21 x.24 x.27 x.28 were blocked while IPs X.22 x.26 were not. :::::more confused:::: Then after reset of the main TZ170 they come back to life.
I have replaced the unit now with the TZ190 but I will leave this open a bit longer incase that we have the same issue or other input is found.
ASKER
I have decided to scrap that firewall. But i believe that you have given some very good advice. I am giving you the points becuase it may help someone else.
I just believe that this firewall was dying a slow death.
I just believe that this firewall was dying a slow death.
ASKER
Thanks for your help.
heh
I'm beginning to suspect something like a dead bit in a register. I had a parallel printer one which was printing apparent garbage - but close inspection showed that characters with even -numbered ASCII codes came up OK but those with odd-number codes came up as the adjacent even-numbered character... the cable had a broken conductor for the LSB of the data byte!
I'll be very interested to hear if you get the problem back with a *different* unit.
You do recall that if it's on 8x5 or 7x24 support, the unit is also covered for hardware swap-out?
I'm beginning to suspect something like a dead bit in a register. I had a parallel printer one which was printing apparent garbage - but close inspection showed that characters with even -numbered ASCII codes came up OK but those with odd-number codes came up as the adjacent even-numbered character... the cable had a broken conductor for the LSB of the data byte!
I'll be very interested to hear if you get the problem back with a *different* unit.
You do recall that if it's on 8x5 or 7x24 support, the unit is also covered for hardware swap-out?
ASKER
Yeah, but the timing was off just a hair for that. We had decided not to renew that one and the following quarter, we were upgrading that one anyway for the TZ190.
We may try and use it for a trade in later when they open the next office.
Thanks
We may try and use it for a trade in later when they open the next office.
Thanks
How you should have it set up is
Local LAN - ALL connected devices should be in the 192.168.1.0/24 network.
Remote LAN - ALL connected devices should be in the 192.168.5.0/24 network.
If the SONICWALL that is the end-point of the VPN is NOT also the Default Gateway for the LAN then you will need to fix up with static routes as appropriate (can give more info if you can give a better network diagram).
All devices MUST have a Default Gateway configured, often with printers users configure an Ip address and a Mask and don't bother with a DG coz they think "why would a printer need to access the internet?"
Then every device on either network should be able to ping and otherwise connect with every other device. No special mappings are needed.
If this *is* how your network is set up - then I'm baffled. I can only suggest that perhaps something else is picking up that address to use - is 5.192 excluedd from the DHCP scope? or Reserved?
If that is NOT how your network is configured... let us know...