# OneGate: expose a communication port inside the VM
**URL:** https://forum.opennebula.io/t/onegate-expose-a-communication-port-inside-the-vm/10814
**Category:** Installation & Configuration
**Created:** [September 12, 2022, 1:41pm UTC](https://forum.opennebula.io/t/onegate-expose-a-communication-port-inside-the-vm/10814 "2022-09-12T13:41:31Z")
**Posts on this page:** 8
**Page:** 1
Hello.
In our setup, the OpenNebula frontend is not exposed on Internet for security reason.
In such a setup, we can’t run a service like [OneKE](https://marketplace.opennebula.io/appliance/b5033eba-cd31-487e-892a-035cd70441ef) on our public network because OneGate is not publicly reachable.
I started reading [libvirt documentation on channels](https://libvirt.org/formatdomain.html#consoles-serial-parallel-channel-devices) to see if there is a way to expose a communication port inside the virtual machine and make `onegate` cli communicate through that port instead.
On the hypervisor side, we may need something to forward the communication 🤔
Before digging more the subject, does someone have an idea or suggestion on that topic?
Regards.
---
Hi Daniel,
yes we are aware of this issue. We’re actively working on providing the “onegate-proxy” service (currently in testing phase), which will be installed on hypervisor hosts. It will be based on [https://www.kernel.org/doc/Documentation/networking/tproxy.txt](https://www.kernel.org/doc/Documentation/networking/tproxy.txt) which will cause all the traffic targeted for 169.254.169.254:5030 (example) endpoint inside guests to be routed via hypervisor hosts. Then something like a ssl tunnel or vpn (between frontends and hosts) could be used to reach the onegate endpoint.
Regards.
---
I have setup a test cluster and I think something is missing somewhere.
Our setup use Open vSwitch and the VM ask for ARP request but get no response:
```auto
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on one-3-0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:30:34.619952 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:35.642198 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:36.666192 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:37.690273 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:38.714226 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:39.738249 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
```
I think that I’ll require some Open vSwitch trickeries 🤔
Does someone have an idea?
---
I continue my tests by trying to get rid of the VLAN isolation by making `/dev/ttyS0` a forward to `169.254.16.9:5030` by adding the following
```xml
```
After the VM start:
- I execute on the hypervisor `nc -ln -p 5030 -s 169.254.16.9`
- Then I execute inside the guest `echo foo | tee /dev/ttyS0`
This makes the `nc` command display `foo`.
Now, I must find a way to make `onegate.rb` communicate with `onegate-proxy` throught this `/dev/ttyS0`.
Regards.
---
Hi,
It seems that the proxy is not a good solution for you after all. Our suggestion would be to modify the templates (Flow and VNF VM) and add third VNET, such that hosts deployed there would have access only to OneGate. Then this VNET would be added to VNF only and with the help of a start script you could configure NAT insde VNF to route OneGate traffic comming from RKE2 nodes. Please let us know if that is something possible to do in your infrastructure, we can provide more detailed description on how to achieve all that.