Messages

Greetings,

I updated from: OPNsense 23.7.3-amd64; FreeBSD 13.2-RELEASE-p2; OpenSSL 1.1.1v 1 Aug 2023.
to: OPNsense 23.7.5-amd64; FreeBSD 13.2-RELEASE-p3; OpenSSL 1.1.1w 11 Sep 2023

I have a /29 static subnet. The last usable address is assigned to a cable modem; the first usable address is assigned to OPNsense. It appears that I can no longer send or receive data on any of the other usable addresses in the subnet. Is there a change in the update, or required by the update, that might cause this to happen?

I'm on my way in to the facility to change out the main OPNsense for the backup OPNsense appliance.

Thanks,
Ted Dawson

Hi Franco,

I've gathered the information you requested, and sent it along.

Thanks,
Ted

Hi Franco,
Just updated to: OPNsense 23.7.4-amd64; FreeBSD 13.2-RELEASE-p3; OpenSSL 1.1.1v 1 Aug 2023.
Double checked the Interface settings; static IPv4 address is specified as x.y.z.249/29.

The error message is:
The following input errors were detected:
The gateway address "x.y.z.254" does not lie within one of the chosen interface's IPv4 subnets.

I'm reluctant to post the full public address, but could send it privately, if that would help.
I have a somewhat complex setup, with multiple WAN circuits from multiple ISPs, multiple VLANs, multiple VPNs, etc. I do know that simply setting up a single WAN / single LAN configuration with this particular ISP and address does not exhibit the Far Gateway behavior that I am seeing.

Thanks,
Ted

Greetings,
I'm running OPNsense 23.7.3-amd64; FreeBSD 13.2-RELEASE-p2; OpenSSL 1.1.1v 1 Aug 2023.

I have a static IPv4 subnet from my broadband cable ISP. OPNsense WAN address is x.y.z.249; ISP equipment address is x.y.z.254; mask is /29. Creating the interface and gateway work fine. I can access the Internet with no problem. When I go to System | Gateways | Single (to enable interface monitoring and add an IP to monitor), I cannot save until I check "Far Gateway". This doesn't seem to cause any problem, but I don't understand why I'm forced to use the option.

I'm curious as to why the software behaves this way.
Thanks

I recently ran into the console error "arpresolve:can't allocate llinfo for <ip addr> on <intf>". I'm writing a brief note on my experience. My primary ISP is broadband cable with static IPv4. I had been using a DSL circuit as a failover, and while it was very reliable, it was not very fast. I had a chance to try out a Netgear NightHawk cellular modem/wireless router, which promised better speed.

I started by connecting a PC (configured to use DHCP) to the Ethernet port on the Netgear device. I was able to determine the public IP by browsing to 'whatismyip.com'. I set the device up using information gathered from the Internet, which consisted mainly of turning WiFi off, and putting it in "passthrough mode" (I figured that was Netgear's term for bridged). Everything seemed to work as expected.

On the OPNSense side, I configured DHCPv4 and DHCPv6 on an open interface. According to OPNsense, the IPv4 interface address (from DHCP) was 10.155.146.127 and the gateway was 10.155.146.1. I assumed that the cellular carrier was using CGNAT. Then I noticed that the OPNsense console was being spammed with "arpresolve: can't allocate llinfo for 10.155.146.1 on igb1" errors. Re-reading the documentation, I noted that the private address of the router was available, even in "passthrough mode" (so, not quite a bridge). I changed the OPNsense interface to use static IPv4 addressing in the 192.168.1.x subnet, and the arpresolve error went away. I was able to use Dynamic DNS to register the public IP behind the CGNAT, and so far the device seems to be working OK.

One other oddity is that DHCPv6 doesn't appear to work quite right. However, that is something for another day. Hopefully this will be helpful to someone.

After updating to these versions:
OPNsense 22.1.4_1-amd64 / FreeBSD 13.0-STABLE / OpenSSL 1.1.1n 15 Mar 2022
I've encountered a problem.

My firewall has three ISP connections for failover. This configuration has been stable for several months. After the update, the Tier 2 and Tier 3 ISP dpinger services are running OK. The Tier 1 ISP dpinger service is not running, and cannot be started. I tried disabling and re-enabling the gateway under System | Gateways | Single, and when I clicked Save, I received the following error message:
"Cannot add IPv4 Gateway Address because no IPv4 address could be found on the interface."
Traffic does seem to be flowing through the Tier 1 ISP connection, and I am reluctant to poke at things during business hours.

I'd be grateful for any suggestions.
Thanks,
Ted

The only thing that occurs - might your DHCP reservations overlap your DHCP pool range? I am running OPNsense 21.7.5 at home, using the DHCPv4 service and the Unbound DNS service. The [LAN] DHCPv4 service is configured as follows:

Subnet: 192.168.124.0/24  |  Available Range: 192.168.124.1 - 192.168.124.254
Range: 192.168.124.100 - 192.168.124.149 <-- Pool of addresses to be assigned dynamically
DNS Server: 192.168.124.1  |  Gateway: 192.168.124.1
Reservations:
192.168.124.50, 192.168.124.52, 192.168.124.54, 192.168.124.56, 192.168.124.58, 192.168.124.60

There are usually about 15 - 20 hosts active at any given time, including the 6 reservations. This basic setup has been running for a couple of years and I've never had any trouble with it.

Hope this helps - good luck.

On occasion I've had a bit of trouble with aliases. Replacing the alias with an actual IP address avoided the trouble. I tried that on the rule above (expanding one rule with an alias to four rules each with an IP address). Unfortunately, it didn't make any difference.

Some additional information: IPv6 is disabled on the firewall (Firewall | Settings | Advanced). After each rule change, I reboot OPNsense.

Next step: I know there are link local addresses on the host interfaces of the systems I'm trying to block. I will include rules to block traffic from those addresses. Not sure where to go after that.

I would really appreciate any help.

Thank you for the screenshot.

There are some moving parts that need to work together in a firewall. The default OPNsense setup is very reasonable for common use cases. Setting up a WAN and LAN interface is usually straightforward; NAT is already set up correctly for common use cases. The only firewall rule that needs to be set up is the one to allow LAN traffic; your LAN firewall rules appear to be correct.

That said, there are certainly more than enough other settings to effectively shoot oneself in the foot. Also, sometimes the universe plays tricks on us. More than once, I have created configurations that have broken stuff to the point that a factory reset was my only way out.

Good luck.

I apologize in advance if this too basic.

Since you can connect via SSH to your OPNsense system, it seems safe to assume that the LAN interface is setup correctly.

Not being able to ping the WAN interface may not be related to the OPNsense configuration. One of my OPNsense systems has a broadband connection over cable and a DSL connection over a phone line. I can ping the cable gateway; I cannot ping the DSL gateway.

Have you created a firewall rule for the LAN interface? There should be at least one rule to allow traffic into the LAN interface.

Good luck.

Thanks for your quick response. The intent is to block four hosts behind the LAN interface from communicating with any destination that is NOT behind the LAN interface (note the !). If I'm wrong about the use of invert in setting up the rule, could you explain in more detail? Thanks.

I need to block off-LAN access for a few hosts. I've reviewed the forum for this - it seems to come up now and then. I've read all of the related threads, and I don't think I've missed anything. That said, the following rule does not seem to be working.

Action: Reject
Interface: LAN
Direction: In
TCP/IP Version: IPv4+IPv6
Protocol: Any
Source Address: Alias for the four host addresses
Source Port: Any
Destination Address: ! LAN net
Destination Port: Any

I'm running OPNsense 21.7.5. The only rule preceding this rule is the automatically generated anti-lockout rule.

This seems like it ought to be a simple thing, but it's not working, and I would really appreciate any help.

Thanks

Greetings,

I am running OPNsense 21.7.4 at home. My ISP is Cox Communications. They run dual IPv4/IPv6 stacks. My addresses are dynamically allocated. My DNS host is GoDaddy. I set up two Dynamic DNS entries to keep my A and AAAA records updated. The IPv4 entry works correctly. The IPv6 entry fails. Here are the relevant log entries with FQDN and IPv6 Public address obscured:

Code Select Expand


2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS: (Error) Repsonse not handled check the following:
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS: (Error) HTTPS Status: 0 PAYLOAD:
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS (xxx6.yyyyyyy.zzz): Current Service: godaddy-v6
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS (xxx6.yyyyyyy.zzz): _checkStatus() starting.
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS: calling https://api.godaddy.com/v1/domains/sawejko.com/records/AAAA/ted6 with body: [{"data":"aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh","ttl":600}]
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS (xxx6.yyyyyyy.zzz via GoDaddy (v6)): _update() starting.
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS (xxx6.yyyyyyy.zzz): running dyndns_failover_interface for wan. found em1
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS (xxx6.yyyyyyy.zzz): aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh extracted
2021-11-09T09:54:50 php-cgi[73998] /services_dyndns_edit.php: Dynamic DNS: updatedns() starting


I'm not unwilling to work on the issue, but my technical skills are limited. I'd be grateful for any assistance or suggestions.

Thank you