When I had mine online, they were less stable, so often wondered if its those random packets that appear at the firewall which is causing a problem.
May be you could log the packets going to the port(s) and see if a packet or series of packets cause the service to crash, so you’ll also need to log the service events in the windows event viewer.
Then when its crashed, look back through the event log, get a time and then look at the logged packets to see what appeared at the same time, and then look for other packets before that crash event in case its more than one thats caused the problem.
Potentially you only have to go back as far as the firewall session timeout window, which can be anything from 1 minute to several hours, its a firewall setting. Windows typically has a two hour timeout, azure only 4-5mins if you are hosting on the cloud.
I cant remember off the top of my head if the IP driver service has a timeout setting or not, but you want it to at least be the same timeout period as your firewall session timeout.
There is a chance that if the IP driver service has a longer timeout period than the firewall, that a carefully crafted packet could be sent after the first firewall timeout period which still affects the IP driver service.
IIRC it was written in Java, so have a look for any bugs that affected the Java runtime thats installed.
Edit.
To elaborate more on the packet logging. The problem with https/443 data is its encrypted and only the IP driver server decrypts the packet. So behind your firewall you could rig up a reverse proxy with TLS inspection.
Courtesy of ChatGPT:
Is there a reverse proxy which can decrypt the packets, log them and the encrypt them again before forwarding to a backend server on port 443 ?
Yes
— what you’re describing is a standard architecture called:
TLS termination + inspection + TLS re-encryption
(or HTTPS → decrypt → inspect/log → HTTPS → backend)
Many reverse proxies and load balancers can do exactly this.
What you want (architecture)
Client → HTTPS :443 → Proxy (decrypt + log) → HTTPS :443 → Backend
The proxy:
- Accepts HTTPS
- Decrypts traffic
- Logs or inspects it
- Creates a new TLS connection to backend
- Re-encrypts and forwards
This keeps encryption on both hops while allowing inspection.
Reverse proxies that support this
NGINX — yes (very common)
NGINX can:
- Terminate TLS from client
- Log decrypted HTTP
- Connect to backend using HTTPS
- Verify backend certificates
- Do mutual TLS if needed
You just change:
proxy_pass https://backend:443;
instead of http://.
This creates:
- client → proxy TLS session
- proxy → backend TLS session (separate connection)
This is normal reverse-proxy behavior.
HAProxy — designed for this
Very common in enterprise environments:
- TLS termination
- TLS inspection/logging
- TLS re-encryption to backend
- Layer 7 filtering
- Performance optimized
Often used for banking / high-security networks.
Apache HTTP Server — also supports it
Using:
mod_ssl
mod_proxy
mod_proxy_http
Less common than NGINX/HAProxy but works.
Specialized TLS inspection proxies
TLSPROXY
Designed specifically for TLS handling:
- Terminates HTTPS
- Forwards to HTTPS backend
- Can inspect traffic
- Automatic certificates supported
Enterprise / commercial systems
(used in corporate networks)
- F5 BIG-IP
- Citrix ADC
- Akamai edge proxy
- Cloudflare proxy
These do TLS inspection + re-encryption by default.
What happens internally
Important concept:
The proxy does not forward the original encrypted packets.
Instead it:
- Decrypts client request
- Processes/logs HTTP
- Creates a new HTTPS request
- Sends that to backend
Two independent TLS sessions exist.
Why people use this design
- Keep end-to-end encryption
- Log/inspect traffic
- Add security filters/WAF
- Authenticate users
- Protect internal networks
- Meet compliance requirements
This is common in enterprise security gateways.
Important security reality
If the proxy decrypts traffic:
- The proxy sees everything
- It becomes a trusted security boundary
- Private keys and logs must be secured
The proxy is effectively a man-in-the-middle by design.
End of ChatGPT
And thats what you want on port 443, and if using port 80, a logger on port 80. This way you’ll get the raw packets to see whats going on and if a packet is causing the IP Driver server to crash or not.
Its the start of a process. If nothing shows up with the packet logging, potentially a bit of reverse engineering with something like Ghidra to see if there are any bugs in the IP Driver service.