Rupert Eghardt
asked on
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.
UPDATE:
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?
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.
UPDATE:
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?
ASKER
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?
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?
Then I cannot see any reason for the failure.
ASKER
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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 255.255.255.0 and all devices on the remote site runs off 255.255.0.0
Can this result in access to some local resources and not to others?
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 255.255.255.0 and all devices on the remote site runs off 255.255.0.0
Can this result in access to some local resources and not to others?
ASKER
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?
image.jpeg
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?
image.jpeg
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?
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?
ASKER
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.
https://social.technet.microsoft.com/Forums/forefront/en-US/46f90acc-456e-4aa8-a8b3-e05bdb05a2e2/tmg-static-route-to-separate-internal-network-not-working?forum=ForefrontserverMC
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.
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.
https://social.technet.microsoft.com/Forums/forefront/en-US/46f90acc-456e-4aa8-a8b3-e05bdb05a2e2/tmg-static-route-to-separate-internal-network-not-working?forum=ForefrontserverMC
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.
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).
ASKER
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 ..
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 ..
ASKER
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.
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.
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.