Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Ping Test drops with code 727 from VPN to internal X interface



I found this other article, but it doesn't quite match the configuration conditions of our setup. I did try the idea in it anyway but it still didn't work.

I cannot get a ping reply from the Sonic Wall router at one site over a Site to Site VPN. But I can get a ping reply from any other device on that network with the Sonic Wall router over the VPN. It is driving me nuts!!

So our scenario:


X0 left as default LAN zone


X2 as under a Zone called Staff, with X3, 4, 5 as portshield to X2

W0 Layer2 Bridge to X2, with a W0:36 lan tag and subnet 192.168.36.x for Guests on Wifi while staff connect on the primary W0 getting a 192.168.6x ip due to the Bridge. I followed the steps at this article to do that, tested staff and guest access / limitations and it worked beautifully.

A Site to Site VPN tunnel is up and running to multiple other offices.

On site, I can ping the router at its address of 6.1, and any device in the site as well, such as a network switch at 6.241.

From a VPN site, I can also ping 6.241 , but a ping to 6.1 will not work. When I used Packet Monitor to capture conditions, I found this Dropped status about the attempt tp ping 6.1 from another site.

I have no rules I can find that should be causing this drop! I also turned off all extras to test, (AV Gateway, Intrusion, Content Filtering, Botnet, etc.) to make sure it wasn't one of those features.

I then tried each one of these manual Policy adds and none of them made any difference.

What is the solution to this insanity ?

Allow Ping from VPN to X2

Allow Ping from VPN to Staff

Allow Ping from WAN to X2

Allow Ping from WAN to Staff


Ethernet Header

Ether Type: IP(0x800), Src=[68:b6:fc:c5:72:22], Dst=[2c:b8:ed:a8:ae:f1]

IP Packet Header

IP Type: ICMP(0x1), Src=[], Dst=[]

ICMP Packet Header

ICMP Type = 8(ECHO_REQUEST), ICMP Code = 0, ICMP Checksum = 19113


DROPPED, Drop Code: 727(Packet dropped - Policy drop), Module Id: 27(policy), (Ref.Id: _2722_qpmjdzDifdl) 1:1)

Category: Firewall Management and Analytics


  • BartManBartMan Newbie ✭
    edited January 13

    Make sure ping is enabled on the LAN interface on both units. By default it is not enabled.

  • JHSDJHSD Newbie ✭

    Hi Bartman,

    Thank you for the reply! So I went back and checked - the X0 interface does have Ping enabled already on it's setting. Not sure why that one would matter though actually, because as listed above, I left X0 as the default LAN management (as It is not bridged or setup with portshield to any of the other interfaces. I just use it as a local plugin for admin management. I know, sort of a waste of a usable port but I don't have the need to use every physical port on this device (at the moment).

    I did check under Policy for VPN to LAN , and a Ping allow rule was already there (auto created by the setting on the Lan). I then tried adding one from LAN to VPN to ensure it was two-way but again it didn't produce any reply from

  • JHSDJHSD Newbie ✭

    I should add - while the TZ270w will not reply to a Ping from the other side of the VPN, I can still open and log in as the Admin over the VPN to 6.1 . But I need the Ping test to work for our monitoring tools. It just keeps thinking it's down right now.

Sign In or Register to comment.