Site-To-Site VPN: Tunnel UP, but no traffic being routed.
Site-To-Site VPN: Tunnel UP, but no traffic being routed.
I am trying to setup a Site-To-Site VPN from "Main Office" to "New Branch" using OMADA.
"Main Office":
- Gateway: ER8411 v1.0: 1.2.2 Build 20240809 Rel.48592
- WAN: public fixed IP, not behind any NAT or extra firewall
- LAN: 192.168.100.0/24, whereby the ER8411 has 192.168.100.1.
"New Branch":
- Gateway: ER7212PC v1.0: 1.2.0 Build 20240716 Rel.80083
- WAN: public fixed IP, not behind any NAT or extra firewall
- LAN: 192.168.2.0/24, whereby the ER7212PC has 192.168.2.1.
Setting up the tunnel works fine. It shows up under "Insights" -> "VPN Status" as connected, in both directions (in/out), on both gateways.
However, no traffic seems to be routed through the VPN tunnel. I have tried ICMP/Ping, TCP/HTTP(80), TCP/SSH(22) and others.
Even the gateways (192.168.100.1 and 192.168.2.1) cannot ping each other. No firewall rules set. Firewall Options are default (Broadcast Ping, Receive Redirects, Send Redirects, SYN Cookies all ENABLED) on both gateways.
Interesting Detail: From the same "Main Office" gateway we are successfully running a Site-To-Site VPN to another branch, let's call it "Other Branch". Settings are basically the same, and the gateway at the "Other Branch" is also a ER7212PC v1.0, 1.2.0 Build 20240716 Rel.80083. It's LAN is 192.168.200.0/24, whereby the gateway has 192.168.200.1. All traffic between these two subnets (192.168.100.0/24 <--> 192.168.200.0/24) works as expected. From both sides I can ping the "other" gateway as well as any devices behind. All TCP and UDP traffic gets routed as expected.
But for "New Branch", no luck. And Idea what I am missing? Thank you for any advice.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @RaRu
Thanks for posting in our business forum.
RaRu wrote
Last time I had an issue with VPN config (OpenVPN client couldn't connect to the server) I just decided to delete the OVPN server config, reboot the device and create totally new OVPN server.
Then it started to work.
I know it's not a solution but maybe there's something in routers memory/config that's making a problem. Maybe it would be a good idea to start again from the very beginning.
He should've pinged the gateway of the remote end. From 192.168.100.1 to 192.168.2.1, and verify the tunnel status.
As you can see the tunnel is up and this indicates the IPsec has been established. I am more inclined to believe that the issue no longer resides on the router side.
- Copy Link
- Report Inappropriate Content
> Hmmm, out of curiosity... Can you try to disable Block WAN ping option as well as enable Broadcast Ping?
> (Yes, I know that you were also trying to SSH and other thing except the ping. Just for science!)
I just tried the settings from your screenshots... Unfortunately nothing has changed. But thank you anyways!
- Copy Link
- Report Inappropriate Content
> He should've pinged the gateway of the remote end. From 192.168.100.1 to 192.168.2.1, and verify the tunnel status.
As described already, any attempt to ping "through the tunnel" failed. Cannot ping the remote gateway from either side, and also cannot ping any devices behind it. Also tried traffic other than ICMP, with no luck. No routing seems to take place.
> As you can see the tunnel is up and this indicates the IPsec has been established. I am more inclined to believe that the issue no longer resides on the router side.
So what else could it possibly be?
Also to consider from my very first post:
From the same "Main Office" gateway we are successfully running a Site-To-Site VPN to another branch, let's call it "Other Branch". Settings are basically the same, and the gateway at the "Other Branch" is also a ER7212PC v1.0, 1.2.0 Build 20240716 Rel.80083. It's LAN is 192.168.200.0/24, whereby the gateway has 192.168.200.1. All traffic between these two subnets (192.168.100.0/24 <--> 192.168.200.0/24) works as expected. From both sides I can ping the "other" gateway as well as any devices behind. All TCP and UDP traffic gets routed as expected.
- Copy Link
- Report Inappropriate Content
Hi @Vento
Thanks for posting in our business forum.
Vento wrote
> He should've pinged the gateway of the remote end. From 192.168.100.1 to 192.168.2.1, and verify the tunnel status.
As described already, any attempt to ping "through the tunnel" failed. Cannot ping the remote gateway from either side, and also cannot ping any devices behind it. Also tried traffic other than ICMP, with no luck. No routing seems to take place.
> As you can see the tunnel is up and this indicates the IPsec has been established. I am more inclined to believe that the issue no longer resides on the router side.
So what else could it possibly be?
Also to consider from my very first post:
From the same "Main Office" gateway we are successfully running a Site-To-Site VPN to another branch, let's call it "Other Branch". Settings are basically the same, and the gateway at the "Other Branch" is also a ER7212PC v1.0, 1.2.0 Build 20240716 Rel.80083. It's LAN is 192.168.200.0/24, whereby the gateway has 192.168.200.1. All traffic between these two subnets (192.168.100.0/24 <--> 192.168.200.0/24) works as expected. From both sides I can ping the "other" gateway as well as any devices behind. All TCP and UDP traffic gets routed as expected.
The table shows up there but there is no link which is pretty strange.
If you can make sure there are no overlapped VLAN interfaces in any of the sites, consider redoing the ER7212PC IPsec.
If necessary and capable, you can Wirehshark, I would like to have a capture of the WAN and see how IPsec establishes.
- Copy Link
- Report Inappropriate Content
Dear @Clive_A and others...
WE FINALLY SOLVED IT !!!
The problem cause was:
- Our Upstream IP Provider did not route ESP Traffic correctly.
Why it took so long to solve:
- The gateways show the tunnel as "Connected", even when ESP Traffic is not possible.
- The TP-Link documentation, respectvely @Clive_A 's answer (https://community.tp-link.com/en/business/forum/topic/658494) makes one believe that NAT-T (encapsulating ESP via UDP[4500]) is on by default, which does NOT seem to be true.
The solution was:
- Make the Upstream IP Provider change settings for ESP to be routed correctly.
My big wishes towards TP-Link:
- Make the tunnel NOT show as connected when no ESP traffic is possible.
- Make NAT-T an option that can be turned on and off. - - that would have made debugging sooooo much easier!
- Make internal LOGFILES concerning the VPN tunnel available. - - that would have made debugging sooooo-ooo-ooo much easier!
Thank you to everybody who participated.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 476
Replies: 16
Voters 0
No one has voted for it yet.