Messages

So a "Reject" is translated to "Block Return@:
       This  causes  a  TCP  RST to be returned for tcp(4) packets, an
       SCTP ABORT for SCTP and an ICMP UNREACHABLE for UDP  and  other
       packets.

Thanks for the info, But for me ( and I may have done it wrong),  a tcpdump did not reveal any ICMP Unreachable ( in case of my icmp Ping) but as mentioned, that could be an upstream issue.

Thanks all

ok, thanks for digging into this so deeply.

so to summarise
* Upstream issue with PF for icmp-reply
* "BLOCK" instead of Reject is also a know upstream issue

Thanks for the explanation. I just need to live with this I Guess.

I want the Notification!

dropping traffic is one thing, and it works. I like the >/dev/null route approach, which may facilitate your hardware better, but thats not what I want to achieve.

I do have an application which probes first for a Private IP, If that is not possible it falls back to Public IP. In Order to fail to Public IP Faster, an icmp unreachable or admin-prohibit would be required, and this is my understanding of the "REJECT" action.

By the Way, on the Interfaces I did deactivate "Block [privat|bogon]networks"; I also checked nat rules and hit logging on each ruleset.

But changing the rule from "REJECT" to "BLOCK", either incoming on lan or outgoing on WAN does not give me an icmp-reply.

Hello Team,

My understanding off a reject rule is,  that it will send an icmp administrative Prohibit, or similar.

e.g. I do have a Rule that Denies all traffic leaving my WAN interface Destination RFC1918 IP range to REJECT.
If I ping from a host towards e.g. 10.100.1.1 I expect to receive an ICMP Reply with admin-prohibit, but I do not see a reply at all.
Having a look at the Firewall-Logs it only shows as a 'BLOCK'.

Is my understanding right? Did I miss a change?

TIA Feelx

Ok, and If you did not have a lease before or no /var/db/dhclient.leases.* file is present, it will continue sending dhcp-request ....




--- This might be a total corner case, which may not happen in properly configured network.... But I just hit that.
So dhclient will delay boot around 90 Seconds, if not receiving a valid dhcp-lease.

I will just create a cronjob to run dhclient every 15 minutes..

Ok Update..

I set up a dedicated opnsense Virtual Maschine Box between two vlan interfaces of my main Box.
* I set console to serial, autologin enabled so it should autologin to the  OpnSense  right after boot.
* I configured my mac to ping the LAN interface of Testbox
* I configured my MainBox to NOT Send DHCP on that VLAN to WAN-Testbox

Ok reboot time is a little longer from Reboot to Ping is about 45 Seconds

Code Select Expand

21:11:26.693542 64 bytes from 10.225.4.10: icmp_seq=5 ttl=64 time=3.665 ms
21:11:27.696276 64 bytes from 10.225.4.10: icmp_seq=6 ttl=64 time=3.681 ms
[b]21:11:28[/b].700697 64 bytes from 10.225.4.10: icmp_seq=7 ttl=64 time=2.947 ms
21:11:30.707538 Request timeout for icmp_seq 8
21:11:31.711158 Request timeout for icmp_seq 9
21:11:32.715369 Request timeout for icmp_seq 10
--snipp---
21:12:09.842943 Request timeout for icmp_seq 47
21:12:10.844978 Request timeout for icmp_seq 48
21:12:11.847224 Request timeout for icmp_seq 49
[b]21:12:12.[/b]477770 64 bytes from 10.225.4.10: icmp_seq=35 ttl=64 time=15688.881 ms
21:12:12.477851 64 bytes from 10.225.4.10: icmp_seq=36 ttl=64 time=14684.664 ms
21:12:12.477862 64 bytes from 10.225.4.10: icmp_seq=37 ttl=64 time=13683.731 ms

Also the TestBox Imidiately sends DHCP request:

Code Select Expand

21:12:13.933039 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from bc:24:11:c2:0d:67 (oui Unknown), length 300, xid 0x1196fbbf, Flags [none] (0x0000)

Till it finaly sends a last DHCP-Request

Code Select Expand

21:13:23.104930 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from bc:24:11:c2:0d:67 (oui Unknown), length 300, xid 0x37743b83, secs 59, Flags [none] (0x0000)
          Client-Ethernet-Address bc:24:11:c2:0d:67 (oui Unknown)
          Vendor-rfc1048 Extensions

and then the Login // Menu Screen Proceeds.


If the box did get an IP-Address earlier it will configure the last known Address on that interface; Additionally it will configure the 'Alias IP' under interface ! And Stops Sending DHCP-Requests!!!!!!


if DHCP Server is available after this interval, a manual refresh of the interface is required to restore Connectivity.

Also any Virtual-IP on that interface is not Available till the process is either successfully done or in the 'FallbackState'.

[This is the main problem I try to workaround with.]

Thanks for all your replies.

My lan is configured right. I do know what I am doing in Networking in general;-) But never had the need to debug opnsense since 5 Years ; So Kudos to the stability and good documentation!


Yes my ISP,Deutsche Glasfaser,  is kind ignoring DHCP Request till "their" timeout is right.
This is the main problem I try to workaround with.

I want to login via SSH ass soon as it gets up to monitor/debug DHCP etc. That's exactly why I recognised this 'delayed login' issue.

So capturing the DHCP Process on the link , I observed that the box is sending the DHCP-Request quite often and sometimes get a DHCP-NAK ; till their timeout is right. ( debug DHCP-snooping) And this is where I found that the MGMT is not right there... Call me impatient ;-)


So I Rebooted opnsense, takes about 15-20 that I can ping my internal ip of the Firewall. It took about another 10-15 seconds I could login via HTTP or SSH. And now it takes quite a bit longer like 60 - 90 seconds.

What I did to troubleshoot:
1. Shutdown OpnSense-Wan interface on Switchport // physical disconnect ; rebooted Opensense, Ping takes about 15-20 seconds. Login via SSH / HTTPS within 10-15 Seconds possible; un-shut the interface and make dhclient request the lease/prefix and wait for the ISP to finally not respond with DHCP-NAK; ( The issue I need to live with)

2. Using the ' Alias IPv4 address' under DHCP Interface options ( Basic Settings; does not show up in the advanced Section ) ;
   I did understand this feature, that if the DHCP Request times out; this IP Address is used as a 'secondary/backup' ip for the interface.
   With this enabled I rebooted the Box Again; ping 10-15 seconds; login via SSH around another 30-45 seconds later possible. And I did need to refresh the ISP Address again either over interface-> Overview -> Reload cog; or via cli running dhclient .

3. If I do get a DHCP Reply immediately , all is fine and the MGMT is available approx 20 Seconds after reboot.

4. rebooted again to verify if it is fixed or not; Long delay till ssh/http is there.


Currently my family is a little upset about my testing, but I am sure this issue can be replicated in a virtual env.


opnsense is running on phybox; I recall that in a vm observing the console it was stuck right before the login prompt.

If I find time; I will spin up a vm and try to replicate the issue.

So if there are any hints, what could help me in debugging/tshoot I would love to hear this.

 

Well it seems so,

If I start with disconnected WAN interface it boots right through within 20 seconds.

also my internal IP is singable, but I am not able to login via https or ssh.
so I can not actually login to t-shoot int that moment.

Any suggestions what I can do to Tshoot ?

Team,

Unfortunately my ISP DHCP is not working like expected. It does have long delays while answering DHCP request. This might be on intention from my ISP to present DDOS, so it may only allow refresh or renews based on lease time.  So If I need to reboot my OpnSense Box, the Boot Process often sticks quite long waiting for an IP-Address for the WAN Interface. The GUI and SSH does not respond during this time, so I can not do any remote troubleshooting. And this takes too much time for the impatient.

Often I need wait for the Gui to come up and then refresh the WAN interface.

Is there a workaround this ? I thought about giving an Alias IP-to the wan interface to come up faster. But I also had the impression that dhclient then silently dies.


Also dhclient fails quite often

Code Select Expand

/var/log/system/system_20251110.log:<13>1 2025-11-10T09:42:00+01:00 fw02. dhclient 59547 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:43:16+01:00 fw02. dhclient 92764 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:44:32+01:00 fw02. dhclient 9958 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:45:48+01:00 fw02. dhclient 23794 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:47:04+01:00 fw02. dhclient 49297 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:48:20+01:00 fw02. dhclient 64839 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:49:36+01:00 fw02. dhclient 79970 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:50:52+01:00 fw02. dhclient 95641 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:52:08+01:00 fw02. dhclient 55318 - [meta sequenceId="3"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:52:46+01:00 fw02. dhclient 58830 - [meta sequenceId="4"] New IP Address (igc0): 100.90.13.75
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:52:46+01:00 fw02. dhclient 59179 - [meta sequenceId="5"] New Subnet Mask (igc0): 255.255.0.0
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:52:46+01:00 fw02. dhclient 59614 - [meta sequenceId="6"] New Broadcast Address (igc0): 100.90.255.255
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:52:46+01:00 fw02. dhclient 59884 - [meta sequenceId="7"] New Routers (igc0): 100.90.0.1
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:53:24+01:00 fw02. dhclient 74079 - [meta sequenceId="8"] dhclient-script: Reason FAIL on igc0 executing
/var/log/system/system_20251110.log:<13>1 2025-11-10T09:54:40+01:00 fw02. dhclient 88471 - [meta sequenceId="1"] dhclient-script: Reason FAIL on igc0 executing


Could someone give me some hints to debug this further ?

Thanks

Versions
OPNsense 25.7.7_4-amd64
FreeBSD 14.3-RELEASE-p4

Hello Team, I noticed that if you use DNSMasq and add static Hosts the FQDN alias will also be a host entry for the IPv4 address in the Host file.

Could that be changed into the DNSMAQ CNAME Syntax? That would also allow all IP-Addresses for the host to have the alias.

from DNSMASQ

Code Select Expand

> --cname=<cname>,[<cname>,]<target>[,<TTL>]
    Return a CNAME record which indicates that <cname> is really <target>. There is a significant limitation on the target; > it must be a DNS record which is known to dnsmasq and NOT a DNS record which comes from an upstream server. The cname must > be unique, but it is permissible to have more than one cname pointing to the same target. Indeed it's possible to declare > > multiple cnames to a target in a single line, like so: --cname=cname1,cname2,target

    If the time-to-live is given, it overrides the default, which is zero or the value of --local-ttl. The value is a positive integer and gives the time-to-live in seconds.