HEX-NET and CrossSubnets

[golfi_vend]

Hey,
Continuing issues only I will have.

HEX-NET and WPA3

Tried search, but either too short message or didn't exist. :) It seems HEX-NET2 doesn't support WPA3...Is this limitation of HW or SW? And Yes I have IoT network aswell. :)

forums.ross-tech.com

Initially I wanted to complain that I can't use HexNet over subnets, but I have now found out what was the blocker.

When fixing IP to HexNet VCDS does send out UDS packet and get's reply. And I still got error message in VCDS.


But then for Test I enabled from IoT to Main subnet firewall on router.



As You can see the communication starts from HexNet side, which if IoT rules are in place get's blocked as new connection.

Any good reason why HexNet initiates TCP not VCDS? VCDS first would allow STATE in firewall memory and wont plain reject the packet.

 

[gawied]

It was a design decision at the beginning that the HexNet initiates the TCP connection not VCDS. One of the reasons was to allow for the case where VCDS cannot reach the HexNet, i.e. when it is behind NAT, on a different network, or in the cloud.

As far as I know, you need to open up port 10002 in your firewall to allow this to work - @Shaun to confirm.

 

[Shaun]

As far as I know, you need to open up port 10002 in your firewall to allow this to work - @Shaun to confirm.

Yes that is how it works.

 

[golfi_vend]

Thanks, that helps clarify the behavior.


I’m interested in understanding the reasoning behind the original design.


You mentioned that having HEX-NET initiate the TCP connection can help when VCDS cannot directly reach HEX-NET, such as when HEX-NET is behind NAT or located on another network. Could you explain how that works in practice? Wouldn’t HEX-NET still need to know an address at which it can reach the VCDS PC, meaning that NAT or firewall restrictions on the VCDS side could create a similar challenge in the opposite direction?


Was the connection direction primarily chosen for a particular network topology or use case?


I think the IoT use case is also quite relevant for HEX-NET because, as far as I know, it doesn’t support enterprise Wi-Fi authentication using username/password or certificate-based authentication. That makes placing it on a separate IoT/device network fairly natural in environments where the main WLAN uses enterprise authentication. For comparison, interfaces such as the VAS 6154A support certificate-based WLAN authentication.


With the current design, TCP/10002 appears to require an explicit rule allowing new connections from the HEX-NET/IoT network into the client network.


I’m also interested in the discovery mechanism. As far as I can tell, VCDS sends discovery broadcasts both to the directed broadcast address of the PC’s current IPv4 subnet and to the limited broadcast address 255.255.255.255.


Could you share the reasoning for using IPv4 broadcast discovery? Was this intended to support particular legacy environments or simplify compatibility? For modern segmented networks, would a mechanism such as mDNS/DNS-SD be a possible alternative or future consideration? mDNS can be selectively reflected between VLANs by many routers and firewalls, which may make it easier to support discovery across controlled network boundaries.




Thanks for sticking with me and out of blue questions.

 

[Shaun]

One of the main driving factors here was simplifying the number of configurations that the interface needs to support, it is essentially the same mechanism whether the interface is connected to the cloud server or to VCDS, hence why VCDS is effectively acting as the server here.