VPN tunnel up, but no pings or remote resource access

Hi Guys,

I have a VPN tunnel configured between two sites.  It shows "IPsec SA Established"
However, I am unable to ping any resources from local to remote, or visa versa.
The logs show "Failed 1 of 3 times to get DPD R-U-THERE-ACK from peer "xxx.xxx.xxx.xxx[500]"

It's been working all along, until I added a firewall "allow" rule for a network printer, it unexpectedly stopped working.
I hard rebooted both routers, and still no joy.

I just disabled the new rule, did a soft reboot and the channel is back up!
I am confused, the rule is straight forward (attached), and cannot see how that can break the channel?
VPN Inbound Rule
Rupert EghardtProgrammerAsked:
Who is Participating?
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
A VPN connection is considered to be trust-worthy by default. This is different from WAN traffic - using the VPN, you are either considered to be "LAN" or a different, VPN specific zone.
Reading the manual, I cannot see any means to restrict VPN traffic. Your rules apply only to LAN/WAN/DMZ traffic, which is no part of VPN traffic.
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
We should know what VPN devices this is, and which firmware release it runs.

I agree that there is no obvious reason such a rule should stop the VPN from working. I suspect you blocked all traffic, so the DPD feature for VPNs (Dead Peer Detection, kind of ping on IPsec level between the VPN partners) has been tried to use to keep the tunnel up though idle. And then DPD is not configured to answer back, leading to the tunnel going down after some time (and maybe reestablished by a data packet to transfer immediately or later).

Is the above rule related to the VPN? Doesn't look like. But maybe the firewall is set up without rules (= allow all), and adding the first rule switches to "deny all" default rule.
Rupert EghardtProgrammerAuthor Commented:
Thanks Qlemo,

The device is a Netgear Prosafe VPN firewall FVS336Gv3
Firmware:  4.3.1-14

The firewall rules in question are internal to the VPN router, we only use this router for VPN connection.  (no other function)

I should also mention that the tunnel was down for a couple of hours, until I disabled the "problematic" inbound rule, then started working.  With the rule in place, DPD was also unable to establish a new connection successfully.

There are two other rules on top of the inbound list .. (exactly the same - different local IP's) that was configured some time ago.
These did not cause any problems, in fact allowed successful access to those devices successfully.
These rules also stopped working once the new inbound rule was added.

I don't see an inbound "Default Deny" rule ... when looking at the inbound rule list.

It is almost like the new Inbound rule acted as a "Default Deny" or affected the outbound rule?

Upon enabling the "problematic" rule again, it does not seem to be causing the channel to go down again ... it indeed sounds inconsistent and perhaps firmware related?
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Then I cannot see any reason for the failure.
Rupert EghardtProgrammerAuthor Commented:
Thanks Qlemo,

I still had some VPN access issues.  I deleted all rules, but even with no rules, remote users can still access some local resources via the VPN tunnel, which doesn't make any sense.
The default outbound rule is also set to Deny.

Is it possible that the web interface is out of sync with the actual router config?
I've installed the latest firmware, but it shows no inbound rules under firewall Lan/Wan rules, although internal resources still accessible via WAN (VPN).

Any ideas?
Rupert EghardtProgrammerAuthor Commented:
Thanks Qlemo,

I understand and agree that the router's firewall should not affect the VPN traffic,
What is confusing, is that some resources were inaccessible until we've added inbound firewall rules .. Perhaps this was just fluke.

Local resources are now available from the remote site, without any firewall rules, so it makes sense that the VPN traffic is trusted and thus don't require firewall rules to work.
There is however some devices, such as the network printer in question which is still not accessible via the VPN.
Although the local VPN router can ping the printer and the printer web interface can be accesessed from anywhere on the LAN.

All devices on the local site runs off subnet and all devices on the remote site runs off
Can this result in access to some local resources and not to others?
Rupert EghardtProgrammerAuthor Commented:
Ok, I found the problem.
Workstations with static route to remote site (allocated via DHCP) can be accessed from remote location.

Devices such as printers, cannot be accessed (no ping reply) as they don't get the static route to the remote site.

Is there a way to add the static route to the remote site in the router config, so that printers could talk back to the remote site?
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
It is much, much better to have routes managed on your default gateway, even if they are on the same LAN. Single point of configuration ...
I assume the Netgear is the default gateway. So why doesn't it know about the other site? Or do the printers not have a default gateway set up?
Rupert EghardtProgrammerAuthor Commented:
Netgear router only manages VPN to remote site.
We have a TMG server as the default gateway.
I tried previously setting up a static route to the Netgear in TMG, but failed.  Apparently TMG does not handle these very well.


Hence I opted for static routes on workstations, which worked well, until now we experience the VPN printer access issues ...

Even when making printers default gateway the Netgear, its unable to respond to ping requests coming from the remote site.  Workstations with static route is accessible without any issues via the VPN.
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
There is something else wrong if you cannot ping with the Netgear being the gateway. A static route would not be different to that, and so will not help. Different IP subnet for printers? Anything else different for workstations and printers? Check on a workstation by changing the default gateway temporarily (and remove the static route).
Rupert EghardtProgrammerAuthor Commented:
Printers and workstations on exactly the same network and mask.

Only difference is the static route on the workstations.

I will remove static route from workstation, change gateway and see if it still pings from remote site ..
Rupert EghardtProgrammerAuthor Commented:
Thanks for you help!

Problem was static route on workstations (Windows) and also the VPN router firewall, which did not "actually" have an effect on the "trusted" VPN connections.  Thus playing around with the firewall (my ignorance) did not deliver any new results - which is expected.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.