I have Personal Subscription
I have a current Registration OinkCode
IPFire V193
if I supply the Registered Oinkcode inside IPFire’s Talos Registered field, will IPFire still pull only the delayed Registered rules,
not the fresher Subscription rules?
Currently I have manually installed the Personal Subscription Rules 29200
Sys Log: 6 rule files processed. 16539 rules successfully loaded, 22 rules failed, 0
I believe it pulls the subscription files. However, you need to go to Intrusion Prevention System in the WebGUI and select Customize ruleset. From there you would need to select each of the subscripted-xxx.rules that you would like to have active.
keep working at it. the error message is : (1) Downloading and unpacking new ruleset. Please wait until all operations have completed successfully… (2) Error messages. registered - Could not download latest updates.: Can’t connect to www.snort.org:443 (Connection timed out) Have tried the white list feature..
Sorry, that issue is beyond the realm of my limited expertise. Hopefully someone else on this forum may provide some insight
As far as I am aware that is correct because the oinkcode for the subscription rules is different than the oinkcode for the Registered rules.
That is saying that when IPFire tried to access the snort ruleset url that it timed out waiting to get a connection.
The url used for the Registered rulesets and the Subscription rulesets is identical. The only difference will be the oinkcode that for a Subscription option, you will get provided the rulesets without any delay.
I just tested out the Talos VRT Registered ruleset, which I had on my vm testbed but not enabled. The ruleset date was from several weeks ago. I pressed the force update button for it and it successfully updated the ruleset to 1st May so there is nothing wrong with the snort url, at least at this point in time.
If the problem still occurs, what happens if you try the url
https://www.snort.org/rules/snortrules-snapshot-29200.tar.gz
from your browser. Do you get the following message?
and if you try the url
Do you get the home Snort page?
You probably have the firewall blocking the rules download. Create a rule to exempt this.
Analyzing why the connection drops. List is current 2025-05-01 but only Emerging Threats operational. (Emerging Threats + Talos VRT engaged). Emerging Threat list hangs the Safari browser. Provider is snort “registered user”. Snort community replied to the question with blank emails - no use.
registered - Could not download latest updates.: Can’t connect to www.snort.org:443 (Connection timed out) N
You have only created a single rule for www.snort.org and their url resolves via dig to two IP’s
104.16.91.19
104.16.92.19
Try adding another rule for the other IP or making the two IP’s into a Firewall group and making a single rule for that group.
tried that. dig connects. curl does not> [root@ipfire ~]# curl -v https://www.snort.org
Host www.snort.org:443 was resolved.
IPv4: 104.16.91.19, 104.16.92.19
Trying 104.16.91.19:443…
connect to 104.16.91.19 port 443 from 192.168.0.2 port 57272 failed: Connection timed out
Trying 104.16.92.19:443…
connect to 104.16.92.19 port 443 from 192.168.0.2 port 42780 failed: Connection timed out
Failed to connect to www.snort.org port 443 after 39132 ms: Could not connect to server
closing connection #0
curl: (28) Failed to connect to www.snort.org port 443 after 39132 ms: Could not connect to server
You must have some block still in your firewall rules somewhere then, because on my vm system with the Forward Allowed setting I am getting the following with your curl command
curl -v https://www.snort.org
* Host www.snort.org:443 was resolved.
* IPv4: 104.16.92.19, 104.16.91.19
* Trying 104.16.92.19:443...
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
* subject: CN=snort.org
* start date: Mar 21 01:50:13 2025 GMT
* expire date: Jun 19 02:49:42 2025 GMT
* subjectAltName: host "www.snort.org" matched cert's "*.snort.org"
* issuer: C=US; O=Google Trust Services; CN=WE1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
* Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Connected to www.snort.org (104.16.92.19) port 443
This looks to be a Firewall Rule for the machines on your network.
If you have set your Outgoing Firewall section to Blocked then you need to have the firewall rule in the Outgoing Firewall Access section as it is IPFire that is trying to contact snort.org and not a device on your Green Network.
Outgoing rule allowed
You might want to do a short test changing the Outgoing and Forward sections to Allowed, reboot and then test again. That way all the outgoing traffic is allowed.
If that works then you know that you need to look more closely at your firewall rules.
If that does not work then it suggest that you have some other problem, maybe related to your ISP or something else outside of IPFire.
that was done with out a change. in the process fudge was removed and replaced the local clock (127.127.1.0) with a real stratum 1 IP servers. disable monitor
restrict default nomodify noquery
restrict 127.0.0.1
server 129.6.15.28 iburst
server 132.163.96.1 iburst
129.6.15.28 .INIT. 16 u - 64 0 0.000 +0.000 0.000
132.163.96.1 .INIT. 16 u - 64 0 0.000 +0.000 0.000
-Have you tried regenerating oincode?
-On how many devices are you using the same oincode?
-Have you tried downloading directly using your oincode?
Subscription rules are served from this url. If your subscription is active you will receive the latest rules. If not you will receive the free rule package.
https://www.snort.org/rules/<file_name>?oinkcode=<oinkcode>
**<file_name>** - make sure to match the rule package with your snort version.
<small>https://www.snort.org/rules/snortrules-snapshot-29200.tar.gz?oinkcode=6dba58e25333bca69bf31c1c0fbbf3ef47e22f1b</small>
code was regretted. only 1 IPFire in use. Rules Subscription 29200 were manually installed. Since then a Time issue is present and IPFire OS was reinstalled V192 and no backup applied to analyze the problem on bare metal.
Subject: Clean Install — NTP Connections Seen in Tcpdump, but ntpd Never Syncs (.INIT.)
Post: After a clean install of IPFire v192 (no restored backup),
I configured /etc/ntp.conf with verified Google stratum 1 servers:
server 216.239.35.0 iburst
server 216.239.35.4 iburst
server 216.239.35.8 iburst
server 216.239.35.12 iburst
The system time adjusts correctly using ntpdate, and tcpdump confirms that both NTP requests and responses are arriving:
IP 192.168.0.3.57264 > 216.239.35.4.123: NTPv4, Client, length 48
IP 216.239.35.4.123 > 192.168.0.3.57264: NTPv4, Server, length 48
216.239.35.4 .INIT. 16 u - 64 0 0.000 +0.000 0.000
Other details:
• BIOS clock appears correct.
• ntpd starts with no errors.
• restrict lines are standard, with no known misconfiguration.
• DHCP leases are set for 60–120 minutes but interfaces show uptime of 4+ days, which seems strange.
Is this a known issue in v192, or possibly hardware-related? Could it be BIOS RTC malfunction, or a subtle firewall or timing bug?
Would welcome any help confirming where the fault lies or how to better debug ntpd’s sync failure.
Logs are clean, but time never syncs unless manually done via ntpdate.
If it is a dynamic lease then at 50% of the standard lease time (so 30 minutes in your case with 60 minutes as the standard) the client will ask the server if the lease can be extended. In the majority of cases the leases can and will be extended and so the uptime of the lease can be much longer than the standard or maximum lease time.
ntp has been working fine on all my systems for several years now. So I had no problem prior to CU192, with CU192, with CU193 or with CU194 Testing.
Can you show a screenshot of your Time Server WUI page?
Can you also show the firewall rule to allow ntp on IPFire to access the internet.
cancelled the Personal subscription!!
