starred/kvm

Fork 0

mirror of https://github.com/jetkvm/kvm.git synced 2026-03-02 22:58:00 -05:00

Firewall ports not documented or known #270

New issue

Open

opened 2026-02-20 08:21:38 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 08:21:38 -05:00

Owner

Originally created by @discotimetraveler on GitHub (May 15, 2025).

Originally assigned to: @ym on GitHub.

When attempting to isolate KetJVM to a management network/VLAN, the ports to connect to JetKVM are unknown and not documented. This is not related to public internet connectivity.

There is some discussion of this in issue #84 that is linked from the Troubleshooting documentation. But that thread is full of browser issues, OS issues, Internet issues, etc.

This issue is very simple. What ports are required to connect from the browser to the JetKVM and get video working locally? 80/443 are not enough. 80/443 & STUN (3478) are not enough. 80/443 and a huge block of 49152-65535 (as mentioned in issue #84) is almost enough but not quite right, as well as having a huge dynamic port range is very security unfriendly.

If this device requires a massive dynamic port range, and that is seemingly solved "publicly" with Cloudflare and whatever is happening with STUN/TURN as documented here https://jetkvm.com/docs/networking/remote-access, this is not helpful on a local network with firewall segmentation. Not only is this common in Home Lab setups, it's in every Enterprise network everywhere. Having clearly defined and ideally minimal port range known and documented is mandatory.

Originally created by @discotimetraveler on GitHub (May 15, 2025). Originally assigned to: @ym on GitHub. When attempting to isolate KetJVM to a management network/VLAN, the ports to connect to JetKVM are unknown and not documented. This is not related to public internet connectivity. There is some discussion of this in issue #84 that is linked from the Troubleshooting documentation. But that thread is full of browser issues, OS issues, Internet issues, etc. This issue is very simple. What ports are required to connect from the browser to the JetKVM and get video working _locally_? 80/443 are not enough. 80/443 & STUN (3478) are not enough. 80/443 and a huge block of 49152-65535 (as mentioned in issue #84) is almost enough but not quite right, as well as having a huge dynamic port range is very security unfriendly. If this device requires a massive dynamic port range, and that is seemingly solved "publicly" with Cloudflare and whatever is happening with STUN/TURN as documented here https://jetkvm.com/docs/networking/remote-access, this is not helpful on a local network with firewall segmentation. Not only is this common in Home Lab setups, it's in every Enterprise network everywhere. Having clearly defined and ideally minimal port range known and documented is mandatory.

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@sint-sol2023 commented on GitHub (May 19, 2025):

A bump for this issue. I received two JetKVMs last week and must say that the product has a very slick look, is easy to set up, and quite user friendly. However, this device must be isolated from the client network and made accessible on an isolated VLAN which can be reached only via a VPN. This VLAN is not per se a secure place and is set up to allow only a minimum range of ports to reach the machines there. My first idea was allow only the http port 80, but no was as it only allows to see and pass the login page while the whole feature set of the KVM is then not working - USB, video, web console, virtual media are all grayed out.

A solution for now will have to be to remove all restrictions for this devices or to move it to yet another VLAN both of which are not exactly optimal. When I check open sockets I get following output:

# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3893          0.0.0.0:*               LISTEN      267/jetkvm_native
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      192/dropbear
tcp        0      0 :::80                   :::*                    LISTEN      178/jetkvm_app
tcp        0      0 :::22                   :::*                    LISTEN      192/dropbear
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           178/jetkvm_app
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           178/jetkvm_app
udp        0      0 0.0.0.0:56313           0.0.0.0:*                           178/jetkvm_app
udp        0      0 0.0.0.0:36417           0.0.0.0:*                           178/jetkvm_app
udp        0      0 192.168.100.15:42114    0.0.0.0:*                           178/jetkvm_app
udp        0      0 :::5353                 :::*                                178/jetkvm_app
udp        0      0 :::5353                 :::*                                178/jetkvm_app
udp        0      0 :::37885                :::*                                178/jetkvm_app
udp        0      0 :::33143                :::*                                178/jetkvm_app
udp        0      0 fe80::3252:53ff:fe00:a667:56716 :::*                        178/jetkvm_app

If we ignore dropbear, then there are still quite a few TCP and UDP ports and the port 80 is just a tip of an iceberg. Current documentation has yet no information on isolating and securing a JetKVM device on a network. I understand that the product is still fairly new, wildly popular among home labbers, but starts to spill over to SME. Therefore, quite few people would appreciate more documentation/information on this topic.

Thank you once a gain for a great product and software stack and looking forward to more info.

@sint-sol2023 commented on GitHub (May 19, 2025): A bump for this issue. I received two JetKVMs last week and must say that the product has a very slick look, is easy to set up, and quite user friendly. However, this device must be isolated from the client network and made accessible on an isolated VLAN which can be reached only via a VPN. This VLAN is not per se a secure place and is set up to allow only a minimum range of ports to reach the machines there. My first idea was allow only the http port 80, but no was as it only allows to see and pass the login page while the whole feature set of the KVM is then not working - USB, video, web console, virtual media are all grayed out. A solution for now will have to be to remove all restrictions for this devices or to move it to yet another VLAN both of which are not exactly optimal. When I check open sockets I get following output: ``` # netstat -tulpen Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:3893 0.0.0.0:* LISTEN 267/jetkvm_native tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 192/dropbear tcp 0 0 :::80 :::* LISTEN 178/jetkvm_app tcp 0 0 :::22 :::* LISTEN 192/dropbear udp 0 0 0.0.0.0:5353 0.0.0.0:* 178/jetkvm_app udp 0 0 0.0.0.0:5353 0.0.0.0:* 178/jetkvm_app udp 0 0 0.0.0.0:56313 0.0.0.0:* 178/jetkvm_app udp 0 0 0.0.0.0:36417 0.0.0.0:* 178/jetkvm_app udp 0 0 192.168.100.15:42114 0.0.0.0:* 178/jetkvm_app udp 0 0 :::5353 :::* 178/jetkvm_app udp 0 0 :::5353 :::* 178/jetkvm_app udp 0 0 :::37885 :::* 178/jetkvm_app udp 0 0 :::33143 :::* 178/jetkvm_app udp 0 0 fe80::3252:53ff:fe00:a667:56716 :::* 178/jetkvm_app ``` If we ignore dropbear, then there are still quite a few TCP and UDP ports and the port 80 is just a tip of an iceberg. Current documentation has yet no information on isolating and securing a JetKVM device on a network. I understand that the product is still fairly new, wildly popular among home labbers, but starts to spill over to SME. Therefore, quite few people would appreciate more documentation/information on this topic. Thank you once a gain for a great product and software stack and looking forward to more info.

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@maxmeyer commented on GitHub (May 19, 2025):

I second the request for a more complete documentation about firewall ports.

@maxmeyer commented on GitHub (May 19, 2025): I second the request for a more complete documentation about firewall ports.

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@baarcher commented on GitHub (May 19, 2025):

Bump - Until this is published for me JetKVM is a just a (very cool) paperweight. In a Zero trust environment knowing what flows are required is critical and should be published as a matter of course.

@baarcher commented on GitHub (May 19, 2025): Bump - Until this is published for me JetKVM is a just a (very cool) paperweight. In a Zero trust environment knowing what flows are required is critical and should be published as a matter of course.

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@ym commented on GitHub (Jul 11, 2025):

Currently, Pion uses the full range of ephemeral UDP ports (1024–65535), covering nearly all available UDP ports. We’re planning to introduce a feature that allows users to override this setting and specify a smaller port range.

In the meantime, it may be advisable to permit all outgoing UDP ports to ensure full functionality.

Additionally, many cloud-based features rely on dynamic IP ranges. To ensure proper operation, such as with STUN or JetKVM Cloud, you may need to allow all IP ranges from Cloudflare.

@ym commented on GitHub (Jul 11, 2025): Currently, Pion uses the [full range of ephemeral UDP ports](https://github.com/pion/webrtc/blob/4c1af4c3e6cbc596fe75329bbcc3a802a2a19453/settingengine.go#L202C28-L202C49) (1024–65535), covering nearly all available UDP ports. We’re planning to introduce a feature that allows users to override this setting and specify a smaller port range. In the meantime, it may be advisable to permit all outgoing UDP ports to ensure full functionality. Additionally, many cloud-based features rely on dynamic IP ranges. To ensure proper operation, such as with STUN or JetKVM Cloud, you may need to allow all IP ranges from Cloudflare.

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@J0E6469 commented on GitHub (Nov 3, 2025):

Any update on this?

@J0E6469 commented on GitHub (Nov 3, 2025): Any update on this?

deekerman commented

2026-02-20 08:21:39 -05:00

Author

Owner

@purepani commented on GitHub (Dec 26, 2025):