R600vpn
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
R600vpn
Region : Argentina
Model : TL-ER6120
Hardware Version : V1
Firmware Version :
ISP :
We have a TP-Link R600VPN router that has an IPSec VPN connection to an old firewall that we are migrating away from and over to a new firewall (a Check Point 4400 series appliance). After changing the remote end IPSec peer address on the TP-Link router, we have been having inconsistent connectivity back to the central location. Initially we thought this to be a VPN incompatibility or that we had something misconfigured.
After some troubleshooting we were able to verify that the VPN tunnel and related tunnel management communications (IKE traffic) were performing normally, we could verify that the connection was staying up, so we investigated further.
We worked with one particular computer on the TP-Link LAN with a X.X.X.102/24 IP address and a computer on the remote network with IP address Y.Y.Y.2/16 to troubleshoot with and observed the following behavior:
1. We were able to ping each others’ computer in both directions and get responses from each other.
2. It seemed I could trigger a “failure” event by running “SuperScan” from y.2 to rapidly ping and port scan the X subnet to discover responding devices.
3. When the failure event happened neither of us could ping each other anymore, we would get timeouts. This is why we thought perhaps there was an issue with the tunnel. But further investigation revealed something else…
4. Once it appeared connectivity was “restored” we would try again, but this time I had Wireshark running on my y.2 computer. Once I “triggered” the “failure” event again, and we could no longer ping each other, in Wireshark I noticed that the x.102 initiated ping packet was still traversing the VPN tunnel to arrive at my interface and I could see my reply going back, but still he would get no reply.
5. During the “failure” when I initiated the ping I could see my packet leave my computer heading toward him and I could see our Check Point firewall permit the ping, but I would still get the timeout on my side; I’m assuming because my packet never made it to his interface.
6. During this failure event, while still unable to ping each other from x.102 and y.2, he tried pinging y.1 and got a reply! So I logged on to y.1 and was also able to ping him!
I believe this further confirms that the VPN tunnel is working. So I am beginning to think that something on the TP-Link is selectively blocking certain communications. Is there any way to troubleshoot this issue from the TP-Link router? Any logging we can turn on and investigate or something?
X.102’s Windows firewall is off and there is no other software (antivirus, third-party firewall, etc) installed that would cause a timeout on x.102 or y.2, and the Check Point firewall logs do not show any block either, only permit actions.
Model : TL-ER6120
Hardware Version : V1
Firmware Version :
ISP :
We have a TP-Link R600VPN router that has an IPSec VPN connection to an old firewall that we are migrating away from and over to a new firewall (a Check Point 4400 series appliance). After changing the remote end IPSec peer address on the TP-Link router, we have been having inconsistent connectivity back to the central location. Initially we thought this to be a VPN incompatibility or that we had something misconfigured.
After some troubleshooting we were able to verify that the VPN tunnel and related tunnel management communications (IKE traffic) were performing normally, we could verify that the connection was staying up, so we investigated further.
We worked with one particular computer on the TP-Link LAN with a X.X.X.102/24 IP address and a computer on the remote network with IP address Y.Y.Y.2/16 to troubleshoot with and observed the following behavior:
1. We were able to ping each others’ computer in both directions and get responses from each other.
2. It seemed I could trigger a “failure” event by running “SuperScan” from y.2 to rapidly ping and port scan the X subnet to discover responding devices.
3. When the failure event happened neither of us could ping each other anymore, we would get timeouts. This is why we thought perhaps there was an issue with the tunnel. But further investigation revealed something else…
4. Once it appeared connectivity was “restored” we would try again, but this time I had Wireshark running on my y.2 computer. Once I “triggered” the “failure” event again, and we could no longer ping each other, in Wireshark I noticed that the x.102 initiated ping packet was still traversing the VPN tunnel to arrive at my interface and I could see my reply going back, but still he would get no reply.
5. During the “failure” when I initiated the ping I could see my packet leave my computer heading toward him and I could see our Check Point firewall permit the ping, but I would still get the timeout on my side; I’m assuming because my packet never made it to his interface.
6. During this failure event, while still unable to ping each other from x.102 and y.2, he tried pinging y.1 and got a reply! So I logged on to y.1 and was also able to ping him!
I believe this further confirms that the VPN tunnel is working. So I am beginning to think that something on the TP-Link is selectively blocking certain communications. Is there any way to troubleshoot this issue from the TP-Link router? Any logging we can turn on and investigate or something?
X.102’s Windows firewall is off and there is no other software (antivirus, third-party firewall, etc) installed that would cause a timeout on x.102 or y.2, and the Check Point firewall logs do not show any block either, only permit actions.