@MurphyGE 

Some lose the connection. Not all?

That'd be strange. So, when your "clients" lose the connection, will you be able to ping the remote gateway from the clients? Will you be able to ping from the diagnosis tools from the router to the other site? Same, the remote site's gateway. 

  @GRL 

So, I realized precisely with firmware 2.3.0. I have a monitoring center with Zabbix that monitors the remote ER605s and some clients behind it.

I noticed that Zabbix was losing communication with the clients behind it for no apparent reason, but with Omada everything is normal

In my scenario, i have a UTM firewall as a responder and the remote Omadas as initiators Since my need was only to monitor the assets behind the remote Omada, I created a WAN/in ACL in my internal network behind the responder for the internal network behind the initiator (remote Omada).Since then, everything has been apparently normal.

Before creating this new ACL, I only had two, one (first) to allow the clients behind the initiator Omada to access the network behind the responder and another (second) to block some clients from accessing the internet. In version 2.2.6, everything was working normally.Importantly, I have hardware version v2 and v2.20.

  @MurphyGE 

MurphyGE wrote

  @Clive_A 

 

I can normally ping via Controller Server or my host to all the remote Omadas. Both are behind the Firewall that has IPSEC connections to the Remote Omadas. My Firewall is the responder and the remote omadas are initiators.However, I cannot access the clients behind the remote omadas that present this intermittent symptom.When the problem occurs, I just need to reset the ipsec connection and everything returns to normal. Hours or days later, the problem occurs again.As a workaround, I created a test ACL via WAN/IN, allowing access from my network behind the Responder firewall to the internal network of the initiator Omadas.It has been 24 hours and everything is still working normally.

I assume the ACL way would not work. The IPsec is not really sensitive to the NAT. That ACL direction is about the NAT. 

As for the IPsec, it's on the WAN and the negotiation happens on the WAN. 

  @Clive_A 

The only action I took was to create this ACL and move it to the top of the list. For me, there are only two alternatives for what could have resolved the issue:

• either it was the ACL or the fact that creating the ACL in the Controller caused it to resend all the configurations, correcting some other configuration made for version 2.3.0.

To be sure, I will undo the creation of the ACL in just one location and observe the functionality.

Hello,

got that problem too since the update to 2.3.0

Headoffice and three branches with 605 v2 updated to 2.3.0

I got multple vlans between head and branches but only the printer vlan isnt working.

Restarting the vpn s2s connection fixes it, but have to do it every day.

Everything else works, just this vlan stops.

Headoffice

192.168.11.X

Branches

192.168.21.X

192.168.31.X

192.168.41.X

Wan connection is DSL on all places with disconnection from isp every 24 hours.

Since the update everything were good.

  @PhiiiiL 

Check my last post, it might help you. I made an ACL allowing communication between the networks I desire through the WAN port. 

https://community.tp-link.com/en/business/forum/topic/832388?replyId=1584922

for example:

Headoffice

Create ACL 1

• FROM:
  • 192.168.11.x
• TO:
  • 192.168.21.X
  • 192.168.31.X
  • 192.168.41.X
• Through the Interface
  • Interface used as WAN
• ALLOW

Branches

Do the reverse in the Branches

  @MurphyGE 

MurphyGE wrote

  @Clive_A 

 

In this example, I am behind a firewall where I have the IP on the network 172.16.101.0/24.I can ping the remote Omada that has a local interface on the network 172.17.5.254/24, but all the clients behind it do not respond to pings, as shown in the following image. Note that the hosts on the network 172.17.5.0/24 are online.

 

Clientes behind remote omada

 

 

Ping response from my host to the remote omada and its clients. The remote omada responds without issues, but all the clients do not, as shown in the following image.

Important: The ACL that allowed entry via WAN from the network 172.16.0.0/16 to 172.17.5.0/24 is disabled to simulate the problem.

 

 

After creating or enabling the ACL allowing traffic from the network 172.16.0.0/16 to the network 172.17.5.0/25 through the WAN interface, everything starts working immediately and the problem does not happen again.

 

 

 

 

We now don't have a clue. The dev and test team have been informed and are working on it. This might be more helpful if you can provide a diagram of your network, as so far we don't know your diagram for sure. 

Based on the word description, this does not seem to be wrong, but it would be helpful for both of us to see a diagram to straighten out the clues and the network. Please specify the IPs in the diagram and the test devices in this reply.