Messages

Yes can confirm. Found this also myself before I saw your answer but this fixed the issue. Not sure why, but it works again.

Hello,

We did the upgrade on our OPNSense DEC3850 from the latest 23.7.x to 24.1_1 straight. Upgrade itself worked, reboot worked and after the upgrade, LAN users can still surf the internet without any issues. I also see our 2 Gateways (Colt Fiber and Vodafone VDSL fallback) including the GW Groups for it.
We also used Suricata IDS+IPS with Hyperscan on both WAN interfaces.

Again, LAN continued to work normally, surfing was normally possible BUT the Firewall itself was not able to connect to any UDP or TCP services any more. No further 24.1.1 upgrade possible, NTP stopped working and even a "curl heise.de" on the command line immediately failed.

Interestingly, the Firealls Live log showed that even the curl heise.de was allowed (not blocked/was green and allowed with the default "let out everything from firewall (force gw)" rule.
But it failed.

We also tried disabling IDS+IPS entirely (no change) and even enabled "Gateway switching" (was disabled before). Both did not help. Rebooting again, didn't help. All offloadings are disabled too.
NAT Rules also look fine and curious is, The firewall can ping to the internet, e.g. ping heise.de works, but no TCP/UDP conns.

Anyone has an idea? I ran out of them. So again, ALL works except firewall cant reach internet and I can't reach the firewall from WAN (ip whitelisted). Can reach it from LAN though. And we only use IPv4 on WAN/LAN, no IPv6.

Hallo,
wir sitzen aktuell mit ner DEC2750 Appliance und 23.1_6 und diesem Problem fest. Keine pings von der Firewall nach extern und keine Möglichkeit das Repo für ein Update zu erreichen.
DNS geht auch und LAN Traffic (forwarded traffic/NAT) geht auch wunderbar.

Hat jemand inzwischen eine Idee was das ist? Haben IDS/IPS schon komplett disabled, ohne das es hilft.

Hi,
I think I found a solution. I created an "ICMP" "Timestamp" block before the general "ICMP" "any" allow rule. Now I can send timestamp requests using nping but don't get a reply anymore. Here is Before and after. Hope this helps others too :)

Command: nping --icmp --icmp-type 13 <externalFWip>

Before:

SENT (0.0778s) ICMP [x.x.x.x > x.x.x.x Timestamp request (type=13/code=0) id=33558 seq=1 orig=0 recv=0 trans=0] IP [ttl=64 id=17362 iplen=40 ]
RCVD (0.0961s) ICMP [x.x.x.x > x.x.x.x Timestamp reply (type=14/code=0) id=33558 seq=1 orig=0 recv=26415483 trans=26415483] IP [ttl=56 id=32442 iplen=40 ]
SENT (1.0784s) ICMP [x.x.x.x > x.x.x.x Timestamp request (type=13/code=0) id=33558 seq=2 orig=0 recv=0 trans=0] IP [ttl=64 id=17362 iplen=40 ]
RCVD (1.1052s) ICMP [x.x.x.x > x.x.x.x Timestamp reply (type=14/code=0) id=33558 seq=2 orig=0 recv=26416492 trans=26416492] IP [ttl=56 id=62727 iplen=40 ]

After:

SENT (0.0507s) ICMP [10.1.0.132 > x.x.x.x Timestamp request (type=13/code=0) id=12408 seq=1 orig=0 recv=0 trans=0] IP [ttl=64 id=15721 iplen=40 ]
SENT (1.0509s) ICMP [10.1.0.132 > x.x.x.x Timestamp request (type=13/code=0) id=12408 seq=2 orig=0 recv=0 trans=0] IP [ttl=64 id=15721 iplen=40 ]

Hi everyone,

I wanted to ask a specific question regarding ICMP Timestamp requests against OPNSense (CVE-1999-0524). We recently had another Vulnerability Scan during a Pentest and they found this CVE. It was marked as non-critical but I questioned myself if there is a way to disable these on OPNSense.
I only have a ICMP Echo Request/Reply allow rule on the WAN interface so my guess is, that it should be blocked. I also haven't found any other information yet wether this is possible and how.

The specific text added in the Pentest report is this:

THREAT:
ICMP (Internet Control and Error Message Protocol) is a protocol encapsulated in IP packets. It's principal purpose is to provide a protocol
layer able to inform gateways of the inter-connectivity and accessibility of other gateways or hosts. "ping" is a well-known program
for determining if a host is up or down. It uses ICMP echo packets. ICMP timestamp packets are used to synchronize clocks between hosts.
IMPACT:
Unauthorized users can obtain information about your network by sending ICMP timestamp packets. For example, the internal systems clock should
not be disclosed since some internal daemons use this value to calculate ID or sequence numbers (i.e., on SunOS servers).
SOLUTION:
You can filter ICMP messages of type "Timestamp" and "Timestamp Reply" at the firewall level. Some system administrators choose to filter most
types of ICMP messages for various reasons. For example, they may want to protect their internal hosts from ICMP-based Denial Of Service
attacks, such as the Ping of Death or Smurf attacks.
However, you should never filter ALL ICMP messages, as some of them ("Don't Fragment", "Destination Unreachable", "Source Quench", etc) are
necessary for proper behavior of Operating System TCP/IP stacks.
It may be wiser to contact your network consultants for advice, since this issue impacts your overall network reliability and security.
COMPLIANCE:
Not Applicable
EXPLOITABILITY:
There is no exploitability information for this vulnerability.
ASSOCIATED MALWARE:
There is no malware information for this vulnerability.
RESULTS:
Timestamp of host (network byte ordering): 07:04:20 GMT