# IDS/IPS and Long-Lived WebSocket RPC Connections

**Last Updated:** 2026-01-31  
**Document Version:** 1.0  
**Status:** Active Documentation

---

**Purpose**: Sanity-check impact of IDS/IPS on long-lived WebSocket connections to Chain 138 RPC (wss://rpc-ws-pub.d-bis.org, wss://ws.rpc.d-bis.org, wss://ws.rpc2.d-bis.org, wss://wss.defi-oracle.io).

---

## 1. What to allow

| Item | Recommendation |
|------|----------------|
| **Protocol** | WebSocket over TLS (WSS) on port 443 |
| **Hostnames** | `rpc-ws-pub.d-bis.org`, `ws.rpc.d-bis.org`, `ws.rpc2.d-bis.org`, `wss.defi-oracle.io` (and HTTP equivalents for upgrade) |
| **Traffic** | JSON-RPC over WebSocket (text frames); same as HTTP RPC payloads |
| **Connection lifetime** | Long-lived (minutes to hours). Wallets and nodes may hold WS open for subscriptions (e.g. newHeads, logs). |
| **Direction** | Client → 76.53.10.36:443 (then to 192.168.11.167 → 192.168.11.221:8546) |

---

## 2. Typical IDS/IPS considerations

| Risk | Mitigation |
|------|------------|
| **TLS inspection** | If you decrypt TLS to 76.53.10.36, ensure WebSocket upgrade (HTTP/1.1 101 Switching Protocols) and binary/text frames are not dropped or delayed. Some IDS break WS if they buffer or reassemble incorrectly. |
| **Session timeouts** | Do not set short idle timeouts (e.g. 60s) on 443 to the RPC hostnames; WS may be idle between subscription events. 300s+ or no timeout for established WS is safer. |
| **Rate limiting** | Per-IP or per-URL rate limits should allow at least multiple connections and frames per second; WS can have bursty traffic (blocks, logs). |
| **Signatures** | JSON-RPC methods (eth_subscribe, eth_unsubscribe, eth_chainId, etc.) are normal. Avoid blocking on "JSON-RPC" or "eth_" in TLS payloads if signatures are too broad. |

---

## 3. What to avoid

- **Blocking WebSocket upgrade** (e.g. `Upgrade: websocket`, `Connection: Upgrade`) on 443.
- **Aggressive TCP RST** on long idle connections that are actually live WS.
- **Deep inspection** that buffers or modifies WS frames and breaks the JSON-RPC stream.

---

## 4. Quick sanity check

1. From a host that can reach the RPC, open a WebSocket to `wss://rpc-ws-pub.d-bis.org` and send `eth_chainId`; expect `0x8a`.
2. Leave the connection open for 5–10 minutes; send another request. If the second request fails or the connection drops, check IDS/IPS timeouts and TLS/WS handling.
3. Run: `pnpm run verify:ws-chain138` (or `node scripts/verify-ws-rpc-chain138.mjs`). From LAN use `NPM_HOST=192.168.11.167 pnpm run verify:ws-chain138` to hit NPMplus directly.

---

## 5. Summary

- **Allow**: WSS to rpc-ws-pub.d-bis.org, ws.rpc.d-bis.org, ws.rpc2.d-bis.org, and wss.defi-oracle.io on 443, long-lived.
- **Don’t**: Short idle timeouts, blocking WebSocket upgrades, or deep inspection that breaks WS frames.
- **Validate**: Use `scripts/verify-ws-rpc-chain138.mjs` and manual long-lived WS test.