Ip address can not be all zero in Address Group used by IpHelper.
MPERU99
Newbie ✭
Setting up NEW firewall. I have existing firewalls hours away from me, i manage them using the IPsec tunnels that have been created before i started here. on 6.5 I could go into the address group of whatever firewall and add the data and voice networks to group with no issues it would add on the fly and i would eventually see the site-to-site for those address object groups turn green. Most of my firewalls are now on 7.x and now if i try to do the same thing, add address object to an existing IPsec site to site tunnel it gives me an error "Ip address can not be all zero in Address Group used by IpHelper." what the hell the are not zeros ? I could do it before in Gen 6 , now i cant??? how the hell am i suppose to add the ip address objects for the new firewall?
Best Answer
-
CORRECT ANSWERMPERU99
Newbie ✭
This has nothing to do with GVC, this is site to site , turns out YOU HAVE to take down the existing tunnel, on the firewall you are wanting to add the address objects to. then you can slide the address objects into the remote network address object grouping, then you can bring the tunnel back up.. THIS IS !@O^)%ing IGNORANT!!!!!! you did not have to do that on 6.5, in fact one of the firewalls is 6.5 and you can just dynamically add the address objects to the existing and running tunnel. ** I guess it was never suppose to be able to do that ** yet something so useful and DOES WORK on 6.5 supposedly has been "FIXED" in 7.0 , what a crock! they cannot give a good damn reason why other than it wasnt suppose to work that way in 6.5... WELL IT DID AND IT WAS VERY USEFUL! and NOW you have given me yet another reason to NOT use Sonicwall , another CON added to the list
I could understand if you wanting to remove something from an existing production tunnel, you should have to down it to remove.. but to have to stop production tunnels to add objects, that I know are fully capable of doing in 6.5 is just ridiculous. I have to do this after hours or on weekends. like this weekend. So because we maintain our firewalls locally, accessing firewalls located hours away, we use the tunnels to access the firewalls, but if you have to bring the tunnel down.. NOW YOU CANNOT ACCESS THE FIREWALL!!! DUMB!!!!!!!!! SO before hand you have to enable X1 interface to accept logins , (creating a potential vulnerabilities ) access the fire wall from X1(public IP) , take the tunnel down.. add the address objects, bring the tunnel up, verify its up, now access the firewall via the tunnel (Private IP) , disable the x1 login abilities.. this is absolutely &^%^&#!!! stupid!! Sonicwall, you have created more unnecessary work
0
Answers
Hi @MPERU99
Could you check address group in the IpHelper menu. I guess, Some addresses are using by IpHelper service.
@MPERU99
Check below thread. may be it will help you to resolve the iphelper issue.
yes when you create a ipsec site to site tunnel IpHelper creates an automatic IpHelper.. This is NONE editable you can hover over and see the destinations but you cannot edit it.
Oh and by the way!! because SONICWALL is SO FAT!! when loading the 7.0 pages.. we have a firewall that you cannot access X1 (public IP) because the internet connection is only about 20Mbps down and 5Mbps up and so when SONICWALLs fat ass webpage tries to load it times out , therefore that particular 7.x firewall has to be accessed via a remote PC (teamviewer or like at low visual settings) then access the firewall locally, then you can modify.. just stupid!!!!!!!!!!!!!!!!!!!!! Seriously, pull up a network monitor, even through taskmanager, then access a Gen 7 firewall login page, and right after you click on manage button, watch the network RCV spike i have seen it hit over 49Mbps just trying to download the dashboard.. the Gen 6 firewall that was at that location never had an issue, because Gen 6 does not have all the bloat that Gen 7 does.. you know the bells and whistles and pretty visualization that is worthless to real techs that care about function over form. #keep6.5_alive
@MPERU99 about the slow UI I had my fair share about this a while ago, did you tried Firefox as weapon of choice, it seems to handle compression much better.
--Michael@BWC
yes it does not matter which browser you use, the browser will timeout on slow internet connections. Sonicwall move to Gen 7 UI graphical bells and whistles only ruined the management of the firewall, they care more about looks than function anymore, trying to appease someone. and forgetting the real reason they exist. FUNCTION as a FIREWALL first! Sonicwall will also tell you Chrome is the supported browser, I have had that discussion with them too. I have Gen 6 that are reliable workhorses. sure they have some issues too. but the UI is lightweight and never have an issue accessing the UI no matter the connection. #keep-6.5_alive