Issue with Ping using Sonicwall diagnostic tools.
Hello, I'm having a strange issue with a TZ 370.
I have two ISPs configured on my SONICWALL, for the second ISP I had to create a static route because it didn't create the correct one by itself...weird, also had to create a NAT to map the internal IPs to the External IP of this second line (Had to do this because of the way that the ISP is giving us the the external IP).
For some reason I can't ping google using the sonicwall tools but I can ping using a internal computer...
On the tool I pick the port that I've configured for the second ISP, I type in 220.127.116.11 and no luck "18.104.22.168 [0.0.0.1] is not responding" .
Even if I try to ping the configured IPs on this port it doesn't work...gives me the same exact error... What am I missing?
Also, it created some routing rules but for some reason they show up as "turned off" which is also weird, because this happens when the interface is disconnected.
First of all, upgrade your TZ370 to the latest available firmware.
Secondly is your is your second ISP giving you a public IP to use or are you assigning a private IP to your Sonicwall interface and NATing to a public ip? Sounds like what was discussed here.
Yup it looks like it...
They are doing bridge, they gave me a subnet to use between my firewall and their equipment.
Then I have to NAT any to wan with the public IP.
With the configurations that I've made, we can get internet access.
But for example if we try to connect via SSL to the public IP or try to create a IPSec tunnel it doesn't work.
It looks like the Public IP isn't being forwarded to the subnet that is configured between firewall and ISP device.
My last comment in the linked discussion says it all...
Sonicwalls expect to have a public IP on their WAN interface. Any NAT policy you create will likely not include what Sonicwall considers 'management' traffic (e.g. traffic generated by the device itself pings included).
So without the Public IP configured on the WAN, I'm out of luck?
What do you advise?
Ask if your ISP can provide a direct (bridged) connection rather than a routed connection.
Change ISPs to one that can.
Do some research?
1st option, they won't already tried that before.
2nd option, can't really do that now.
3rd option, I did, didn't find anything that could help me out.
Thank you for your help, I'll try something on my side.
I forgot 'Open a ticket with support'.
I think that I was able to fix my problem. :D
Are you going to share so others can find out?
Make sure your DNS configuration in sonicwall is correct as well as ISP.
One more thing check the ISP is added into the Failover & LB group.
The ISP gave me 3 IPs.
2 to configure the connection between my firewall and their device and 1 Public IP.
The public IP wasn't supposed to be configured on the WAN port, but I did it anyway. I configured it on the WAN port with the default gateway pointing to the ISP device (one of the 2 IPs that I had to configure for connection between both my firewall and their device).
After that went to the ARP table and published the IP that I would need to have configured on my WAN port to get communication with the ISP.
Then I had to create a static route like so.
Destination: Public IP
KB - https://www.sonicwall.com/support/knowledge-base/configuring-multiple-wan-subnets-using-static-arp-with-sonicos-enhanced/170503911164326/\
I took this idea from one of the posts that you posted TKWITS, it was someone there called LTENNY that posted this with this route idea with the KB associated.
Now my firewall is responding to the ARP requests without any problem.
Its working for 3 days now without failing, before it failed after 3-10 hours and I had to send a gratuitous arp.
Now I can create IPSec tunnels and I can use SSL VPN.
I hope this makes sense.
It does make sense. I never thought of trying it since I've never run into the situation.
For clarification, rather than use the private IP address you originally had configured on the WAN interface you used the public IP, and static ARPd and routed the private IP address.
Yes, that is it.