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
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
Hi,
What technology of VPN are you using for that? WIreGuard? OpenVPN? IPsec? L2TP?
Could you paste some screenshots of your VPN's configuration for both - Main and Branch offices (blur any sensitive data ofc)?
Cheers :)
- Copy Link
- Report Inappropriate Content
Hi @Vento
Thanks for posting in our business forum.
Like Raru wrote.
Not able to judge what might be wrong. Site-to-Site is a typical use case and it worked as we have tested on all models.
Suspect your config.
- Copy Link
- Report Inappropriate Content
First of all thank you everybody for looking into this.
Here some clarification and the requested config screenshots.
I am using Site-To-Site VPN in "Manual IPsec" Mode.
First of all I would like to clarify:
The tunnel shows up under "Insights" -> "VPN Status" as connected, in both directions (in/out), on both gateways. See screenshots below.
Whenever I change Remote Gateway IP, PSK, or LocalID/RemoteID to anything wrong/silly, the tunnel status goes away under "Insights" -> "VPN Status". As expected.
Whenever I change the settings back to what I have now (see screenshots below), the tunnel comes back as connected. As expected.
--> my conclusion: It's probably not the VPN Policy Settings, but probably a routing issue. I hope I am wrong! :-)
However, even when the tunnel shows "VPN Status" as connected, no traffic seems to be routed through the VPN tunnel.
I have tried ICMP/Ping, TCP/HTTP(80), TCP/SSH(22) and others.
Here the "Insights" -> "VPN Status" from both sides:
"Main Office" gateway:
"New Branch" gateway:
And here are the VPN Settings:
"Main Office" gateway:
"New Branch" gateway:
Any hints greatly appreciated!
- Copy Link
- Report Inappropriate Content
1. Do your TP-Link routers have Public IP? Or those are behing a NAT (ISP's device with public IP)?
2. Can you also show routing table?
3. Do you have any ACLs configured on those Gateways? If yes, can you share those as well?
- Copy Link
- Report Inappropriate Content
@RaRu Thanks!
> 1. Do your TP-Link routers have Public IP? Or those are behing a NAT (ISP's device with public IP)?
Yes, both sides are NOT behind any NAT, and they DO have fixed static global IPs.
> 2. Can you also show routing table?
No static routes have been defined.
The 'actual' routing table (under "Insights"->"Routing Table") shows no mention of any subnet on the "other side".
Do I need to set static routes manually, maybe? I have played around with this, but with no luck so far.
> 3. Do you have any ACLs configured on those Gateways? If yes, can you share those as well?
No ACLs in use.
- Copy Link
- Report Inappropriate Content
I don't see any issue here...
I'm just trying to compare that with my IPsec config which is working...
Can you try to change (in both configurations) the Local Networks setting, from Network to Custom IP - and provide there your local Network address and Mask? Just for testing.
Then disable the server and after few seconds enable it again. Test the ping after that.
BTW. Are you able to test the PING directly from controller (Tools tab)? Does the ping from there work (to ping opposite Gateway)?
- Copy Link
- Report Inappropriate Content
@RaRu thanks again...
> I don't see any issue here...
> I'm just trying to compare that with my IPsec config which is working...
What is most puzzling to me: the tunnel shows as "connected" under "Insights"->"VPN Status"!
So I suspect the gateway WAN IP's are correct, NAT is not an issue, and so on... the VPN handshake is successful! The tunnel is UP!
> Can you try to change (in both configurations) the Local Networks setting, from Network to Custom IP - and provide there your local Network address and Mask? Just for testing.
> Then disable the server and after few seconds enable it again. Test the ping after that.
Just tried that. Nothing changed.
> BTW. Are you able to test the PING directly from controller (Tools tab)? Does the ping from there work (to ping opposite Gateway)?
I have tried everything that came to my mind:
- Tried using commandline ping from devices (Win/Linux) in either local network (luckily I have TeamViewer access as a temporary hotfix at the moment to do this...). I can ping devices and the local gateway fine in either subnet, but NOT accross subnets --> no routing seems to take place. Also tried traffic other than ICMP/ping: HTTP(80), SSH(22), with no luck.
- Tried using PING directly from controller (Tools tab), tried using LAN and WAN interfaces there --> no success. Same as above: Can ping stuff in the local subnet (and also on the big global worldwide net...), but not in the "other" subnet. Not even the LAN IP of the "other" gateway.
- 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!)
- Copy Link
- Report Inappropriate Content
I just recreated the same setting you have in your IPsec and it totally worked for me, right out of the box. No ACLs, no additional routing...
But I do have those ping options allowed.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 469
Replies: 16
Voters 0
No one has voted for it yet.