Messages

Ditto to this, DHCP relay is completely broken now after updating this morning. I see requests going to Infoblox and Infoblox is responding. Devices aren't getting IPs.

Ditto to this. I just switched to new hardware (running opnsense on infoblox appliance) and the install went great. I'm getting intermittent DNS lookup errors when trying to check for updates or do package audits and even trying to manually revert to 23.1.8 from .10, I had to run the command ~10x for the DNS to work consistently across the downgrade process.

I have multiple IPSec tunnels, historically, I use DDNS hostnames  for the endpoints and everything has worked fine, but I'm getting DNS lookup errors in the IPSec logs so I've had to switch to IPs for the endpoints to the time-being.

Additionally, the VTI monitoring tanked and dpinger is reporting 100% loss across the VTI gateway, but traffic is still going across and BGP peers are still forming!

Considering reverting to 22.x..

Are you running BFD with the BGP neighbor? And I'm assuming you're giving enough time for the BGP hold timer to expire, unless you've manually set it low.?

I haven't attempted to create a new interface in a few months, but at some point the process seems to be broken. I've been running opnsense for 3 years now and this is the first time I've had this issue. I create a new vlan, add the interface, configure a static IP and add a any/any firewall rule for the interface (just to make sure) and then I attempt to the ping the interface IP (which should be up) and results are intermittent.

Code Select Expand


Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=4ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=1ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=2ms TTL=64
Reply from 10.0.3.254: bytes=32 time=1ms TTL=64
Reply from 10.0.3.254: bytes=32 time=1ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.


When I ssh into the box check the interfaces, there are some inconsistences between different type of vlans, for example

Vlan 1270 which I've been running for ~3 years has this config and the new vlan 1236 has this minimal config.
Can anyone else duplicate this?

Code Select Expand


igb1_vlan1270: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: LDAP (opt8)
        options=4000000<NOMAP>
        ether 90:e2:ba:25:e3:31
        inet 10.0.1.214 netmask 0xfffffff8 broadcast 10.0.1.215
        groups: vlan
        vlan: 1270 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

igb1_vlan1236: flags=8003<UP,BROADCAST,MULTICAST> metric 0 mtu 1500
        description: F5_VIPs (opt31)
        ether 90:e2:ba:25:e3:31
        inet 10.0.3.254 netmask 0xffffff00 broadcast 10.0.3.255
        groups: vlan
        vlan: 0 vlanproto: 0x0000 vlanpcp: 0 parent interface: <none>
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


In lieu of an integrated keychain that supports key rotation on a certain date/time, I wrote a bash script to rotate the keys instead. However, the keys are hashed or encrypted in the config file. Does anyone happen to know the method the obfuscates the keys inside the ipsec.secrets file?

Has anyone tested sending netflow data to splunk? I've captured data using an intermediate forwarder as well as directly into a splunk indexer. When data is sent to the Intermediate forwarder, the data is gibberish, when it's sent to the indexer it's never received. Thoughts?

I see the con0/1 interfaces under the ipsec config but those probably aren't polled since they aren't a VTI. I've checked 'Do not install routes' to see if I could force a change but that doesn't seem to be working. I still only have the enc0 showing up as the ipsec interface if I check with ifconfig.

Is it possible to have a separate Virtual Tunnel Interface per Phase 1? E.g. with IPSEC actively working with 1 or more IPSEC connections to different locations, the VTI created is 'enc0'. This makes monitoring with NMS difficult since the only interface being reported by SNMP is 'enc0'