Ping Test drops with code 727 from VPN to internal X interface
JHSD
Newbie ✭
Hello,
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:
TZ270w
X0 left as default LAN zone
X1 WAN
X2 as 192.168.6.1 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=[192.168.1.208], Dst=[192.168.6.1]
ICMP Packet Header
ICMP Type = 8(ECHO_REQUEST), ICMP Code = 0, ICMP Checksum = 19113
Value:[1]
DROPPED, Drop Code: 727(Packet dropped - Policy drop), Module Id: 27(policy), (Ref.Id: _2722_qpmjdzDifdl) 1:1)
Best Answer
-
CORRECT ANSWERJHSD
Newbie ✭
SOLVED! Damn this was nuts.
The solution was to create an Access Rule that says -
Allow from VPN (zone) to Staff (Zone) , Source ANY, Destination X2 IP
Apparently choosing "X2 Subnet" for the Destination does not treat the router's own IP address within that subnet as being accessible, even though it IS in that subnet. That's nuts,
0
Answers
Make sure ping is enabled on the LAN interface on both units. By default it is not enabled.
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 192.168.168.168). 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 192.168.6.1
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.