Replies: 3 comments
-
|
https://docs.securityonion.net/en/2.4/proxy.html#proxy Did you set your proxy according to this? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the confusion but I actually installed security onion with the direct internet setting instead of using a proxy and my issue is I am unable to access the webpage. To break down the situation more clearly I recently performed a fresh Security Onion install. After setup, I was prompted to access the web UI. On the Security Onion host itself, everything works as expected — DNS resolution is correct and curl against the FQDN returns an HTTP 307 from nginx. However, when attempting to connect from my Windows 11 workstation (main OS, outside of vmware network I have set up) the browser resolves the hostname but fails with a connection timeout (ERR_CONNECTION_TIMED_OUT). Running Test-NetConnection from Windows confirms that ICMP to the Security Onion host succeeds, but TCP connections to port 443 fail. Environment Security Onion host: 10.0.50.55 (VLAN 50 / Security VLAN) Gateway/DNS for SO: 10.0.50.254 (VLAN 50 in pfsense) Windows 11 client: main OS, outside of VLAN 50, connecting through pfSense pfSense: provides routing, DNS Resolver (host override bbsiem.blueboy.mez → 10.0.50.55) FQDN: bbsiem.blueboy.mez What works On the Security Onion host: nslookup resolves correctly via pfSense, curl -vk https://bbsiem.blueboy.mez returns a 307 redirect to the login page, and ss -tulpn | grep 443 on SO machine shows services listening on 0.0.0.0:443, 4433, and 8443. On pfSense: Diagnostics confirm DNS override resolves properly and Ping to bbsiem.blueboy.mez works. What fails On Windows (main OS, outside VLAN 50): Initially DNS failed, but after pointing DNS to pfSense (10.0.50.254) and flushing cache, resolution now works, nslookup bbsiem.blueboy.mez returns 10.0.50.55, Browser still times out (ERR_CONNECTION_TIMED_OUT), Test-NetConnection 10.0.50.55 -Port 443 → PingSucceeded=True, TcpTestSucceeded=False. Steps taken Installed Security Onion with direct Internet access (no proxy). Configured SO with static IP (10.0.50.55/24), gateway 10.0.50.254, and DNS 10.0.50.254. Created pfSense DNS Resolver override for bbsiem.blueboy.mez. Verified local DNS and HTTPS on SO host. Verified DNS resolution on pfSense and Windows. Added explicit firewall rules in pfSense to allow outside subnets → VLAN 50 on port 443. Confirmed SO service is listening on all interfaces. Added to host override file on windows with SO machine IP and FQDN Despite these steps, Windows clients outside of VLAN 50 still cannot establish a TCP connection to the web UI. Questions Does Security Onion enable any host firewall (iptables/ufw/firewalld/nftables) that would block TCP/443 from remote subnets? Are there expected restrictions on which addresses can reach the web UI (e.g., loopback vs external interfaces)? What logs or diagnostics should I check on the SO host (nginx logs, docker logs, etc.) to confirm if ingress attempts are reaching it? Any guidance for accessing the web UI from an administrative workstation that sits outside the SO VLAN? Current status DNS resolution works everywhere (SO, pfSense, Windows). Web UI is reachable locally on the SO host. TCP/443 connections from Windows to SO consistently fail, suggesting either pfSense inter-VLAN firewalling or host-level firewalling on SO. Thanks in advance for any insight or guidance! |
Beta Was this translation helpful? Give feedback.
-
|
There is a host-based firewall, check this from the CLI |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Version
2.4.170
Installation Method
Security Onion ISO image
Description
other (please provide detail below)
Installation Type
Standalone
Location
on-prem with Internet access
Hardware Specs
Meets minimum requirements
CPU
8
RAM
24
Storage for /
200 GB
Storage for /nsm
125G
Network Traffic Collection
span port
Network Traffic Speeds
1Gbps to 10Gbps
Status
Yes, all services on all nodes are running OK
Salt Status
No, there are no failures
Logs
Yes, there are additional clues in /opt/so/log/ (please provide detail below)
Detail
Hello Security Onion Community,
I’ve run into an issue where I cannot open the SOC web interface. Instead of a certificate warning, I always get:
DNS address could not be found. Diagnosing the problem
I already have a host override configured in pfSense, so DNS resolution itself should not be the problem.
Logs & Symptoms
Nginx error log shows repeated upstream failures:
connect() failed (111: Connection refused) while connecting to upstream,
client: 10.0.50.55, server: ,
upstream: "http://10.0.50.55:9822/api/node"
SOC container is listening on 9822:
0.0.0.0:9822->9822/tcp so-soc
Curl directly to port 9822 fails with TLS if using https://:
curl -vk https://127.0.0.1:9822
error: SSL routines::packet length too long
But using plain HTTP works:
curl -v http://127.0.0.1:9822
< HTTP/1.1 200 OK
This makes me think nginx is not proxying HTTPS correctly to SOC.
nginx default.conf (inside so-nginx container) only serves localhost on port 80 — no mention of 9822 or SOC proxy config.
What I’ve Tried
Verified so-status (all services green).
Verified host override in pfSense.
Confirmed SOC container is running and exposing port 9822.
Confirmed curl works against http://127.0.0.1:9822.
Tried adding manual nginx configs, but container doesn’t persist changes.
Possible Issues
nginx container missing proxy rules to forward traffic from 443 → so-soc:9822.
SSL/TLS mismatch between nginx and soc service (nginx expecting HTTPS, SOC only serving HTTP).
Configuration may have been lost/not applied during setup.
Question
What is the correct way to make SOC accessible over HTTPS?
Should nginx be proxying plain HTTP from SOC (9822) and wrapping it in SSL, or should SOC itself be handling HTTPS?
Any guidance would be helpful.
Thanks in advance!
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions