Hi @PedroPeixoto 

Thanks for posting in our business forum.

PedroPeixoto wrote

  @MR.S 

 

Thank you for taking the time to reply.

 

Would you have information on making that interface available on the UI? I'd like to create access control rules on it.

 

Also,

 

MR.S wrote

  @PedroPeixoto 

policy route for OpenVPN is just around the corner, it is said that it will come in controller version 5.15 

 

What exactly "around the corner" mean in terms of time? Cuz I'm running controller 5.13, cuz 5.14 had a bug on the docker image, and wouldn't run.

I've also been working with my Router in standalone mode. It honestly felt that the controller was very much making things more confusing, and even restricting some functionalities.

 

Docker is not maintained by us and when recoding that to the Docker system, and if there is a bug, we cannot resolve it or adjust that for the Docker.

Understand the migration of the system and it is normal to experience an issue when migrating. It is possible that we will not be able to address what you mentioned in the Docker.

Like the MR.S wrote, PBR for the OVPN is scheduled for V5.15. For a disclaimer, read the original post: https://community.tp-link.com/en/business/forum/topic/625262

Regarding two other questions,

1) Full tunnel mode. If you are the OVPN client, you don't have control over the tunnel mode. Server decides.

2) Local Networks.

Hi @PedroPeixoto 

Thanks for posting in our business forum.

PedroPeixoto wrote

Hello @Clive_A

 

Thanks for taking the time to reply to my thread!

 

My OMADA is indeed the client, but the server is NOT another OMADA router. It's a legacy system running OpenVPN 2.4.0.

 

I'm not aware of any split/full tunnel settings. My VPN server will not push itself as the default gateway (is that what a "split" tunnel means?)

 

I'm afraid I didn't get what you meant by "local networks". Is a way to select which of the local networks are going to be routed to the VPN server?

If you are not in proxy mode, route all to the server, it is a split tunnel.

The local network determines what local network should be using the VPN tunnel.

Hi @PedroPeixoto 

Thanks for posting in our business forum.

PedroPeixoto wrote

OK! Thanks for the added info.

 

I guess this VPN feature is not really a good fit for me: It's configurable enough.

 

In my scenario, the VPN tunnel works to connect the remote site (where the OMADA would be) to a cloud service (The VPN server), where applications then consume services and data (HTTP, Database) hosted on the remote site.

 

The OMADA would need to be very configurable for me to define how each network can talk to one another. IE:

- My LAN can talk to the DMZ, but only on a few services.

- Connections coming from the the VPN (the cloud) should have full access to LAN and DMZ, but cannot be NAT'ed through WAN

- No connections can flow from WAN into any of the local networks without a NAT/Masquerading.

It sounds really strange to describe the things you want in this way. I think it can do that. But from what you described, it seems to not be available on the system. So, we seems to be not on the same page.

Do you have a diagram to illustrate further your points on i.e.?

With all due respect, it sounds like you have not figured out what it means in OVPN. What would be the level of your understanding of the OVPN? So I can explain this specifically.

If you have other opinions or some verification you've done, you can let me know so I can point out if it is normal behavior or not supported.

Hi @PedroPeixoto 

Thanks for posting in our business forum.

PedroPeixoto wrote

Hi  @Clive_A 

 

First and foremost, thank you for taking the time to discuss this with me.

 

Here's a simplified diagram for the network I wish to accomplish with OMADA (Again, the OMADA would be replacing a traditional Linux box acting as a router):

 

 

I'm a web developer, and pretty familiar with Linux Administration, Networks, Routing, Firewalls, and OpenVPN, though working on this has not been my main role for a long time now.

 

My OpenVPN configuration is pretty simple. It creates a TUN interface through which clients can connect and offer their services and data to the VPC to consume, so, in that sense, it's more of a site-to-site network than a client-to-site (where the client usually routes their traffic through the VPN, or consume services within the VPN).

Upon connection, the VPN server learns a few routes from the client, and pushes some routes to it as well, using OVPN's "CCD" files.

 

As you can see, no traffic is routed from the client, through the tunnel, into the VPC. The flow is reversed: The VPC applications use the tunnel to access resources within the clients.

If it is more of a site-to-site, you should refer to the guide in the Configuration Guide label. For this setup, you should create dual tunnels to make the connection bidirectional between them.

When you only access the 10.10.X.X, you are routed. This is a split tunnel. If you intend to forward all traffic from either LAN inside the Remote Site, you use a full tunnel.

The previous answers still stand.

2) You should create dual tunnels. Full tunnel.

3) When the tunnel is up, the remote site clients can access the cloud and they will be proxied by the cloud WAN if 2) is enabled..