Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - edjados

Pages1

22.1 Legacy Series / Re: "There was an error trying to determine the public IP for interface - wan(em0)"

June 21, 2022, 09:23:59 PM

Hi Franco,

I feel extremely silly. I could swear I'd enabled the non-v6 option (i.e. just "Cloudflare API token", not "Cloudflare API token (v6)", but I had obviously misread what I'd set, and misread multiple times.

I've just changed it to the non-v6 option and everything is now working fine, of course!

Thank you for your prompting, hopefully this thread can help anyone who makes this oversight in future.

22.1 Legacy Series / Re: "There was an error trying to determine the public IP for interface - wan(em0)"

June 16, 2022, 08:29:40 AM

Hi Franco,

Apologies for the late response. The WAN interface does indeed have no IPv6 address, however I thought that wouldn't cause any issue. It has an IPv4 address which it grabs via DHCP from my ISP, and it's this IPv4 address which I want to push up to Cloudflare (since my ISP often doesn't renew the lease for the same IP so it changes without notice).

The OPNsense box displays the correct WAN IPv4 address on the dashboard and on the Interfaces > Overview page, so it "knows" it has this IP. This matches the IP which is returned by a > curl http://checkip.dyndns.org <, also.

I assumed that line in the log about there being no IPv6 address was just informational, since it's the IPv4 one it's failing to grab.

I also thought I'd mention I only have one WAN interface, i.e. this isn't in a failover or multi-WAN configuration which I've heard can cause issues with this.

22.1 Legacy Series / "There was an error trying to determine the public IP for interface - wan(em0)"

June 15, 2022, 11:27:40 AM

Hi folks,

I have an OPNsense 22.1.8 box with the os-dyndns plugin installed (version 1.27_3) and configured with my Cloudflare API token. (waiting for os-ddclient to work with CloudFlare tokens before updating to that.)

Unfortunately it isn't working, and the log file indicates it can't source the public IP. The log file entries look like so:

Code Select

2022-06-15T09:54:43	Error	php-cgi	/services_dyndns_edit.php: Dynamic DNS (REDACTED.co.uk) There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface.	
2022-06-15T09:54:43	Error	php-cgi	/services_dyndns_edit.php: Dynamic DNS (REDACTED.co.uk): running dyndns_failover_interface for wan. found em0	
2022-06-15T09:54:43	Error	php-cgi	/services_dyndns_edit.php: Dynamic DNS (REDACTED.co.uk): IP address could not be extracted	
2022-06-15T09:54:43	Error	php-cgi	/services_dyndns_edit.php: Aborted IPv6 detection: no address for em0	
2022-06-15T09:54:43	Error	php-cgi	/services_dyndns_edit.php: Dynamic DNS: updatedns() starting

The important part appears to be "There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface." My OPNsense is connected directly to the Internet (only a fiber modem sits between it) and my ISP does not perform CG-NAT.

I've been told os-dyndns just does a > curl http://checkip.dyndns.org <, and when I do this myself over SSH, I see the correct public IP in the output:

Code Select

root@OPNsenseGateway:~ # curl http://checkip.dyndns.org
<html><head><title>Current IP Check</title></head><body>Current IP Address: 51.183.[REDACTED]</body></html>

I've configured os-dyndns to look at my WAN interface as seen in the log above. Does anyone know what could be going wrong to cause it to fail?

Thanks in advance!

-----
Versions:
OPNsense 22.1.8_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1o 3 May 2022
CPU type: Intel Core 2 Duo E7500 @ 2.93GHz (2 cores, 2 threads)
Load average: 0.24, 0.31, 0.26
Uptime:7 days 13:22:03

22.1 Legacy Series / 'Thermal Sensors' Coretemp CPU temp is stuck on the same value

May 27, 2022, 11:20:36 AM

Hi folks,

I have a very minor issue, but it'd be nice to find the fix for it or at least see if I'm not the only one.

Since installing my OPNsense box 44 days ago, the 'Thermal Sensors' widget CPU temps have remained exactly the same - Core 0 at 44 degrees C., Core 1 at 35 degrees C. (Screenshot attached) These values have not changed at all ever since installation.

Yet this box isn't in a temperature controlled environment, and is totally exposed to the changing ambient air, which has varied by around 10 degrees C since installation. Even if ambient air remained the same, once could expect CPU temps to increase during high load.

I've confirmed the same temps are given when doing a { sysctl -a | grep temperature } over SSH. I've also confirmed the temps remain stuck after unloading and reloading the Coretemp kernel module, with { sudo kldunload -v coretemp } followed by { sudo kldload -v coretemp }

Has anyone ever encountered this issue or know the fix? I was surprised when reloading the Coretemp module didn't fix it, as it looks like it perhaps wasn't re-querying the temps after it was initially started. Versions/hardware info below!

Versions:
OPNsense 22.1.6-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1n 15 Mar 2022
CPU: Intel Core 2 Duo E7500 @ 2.93GHz
Uptime: 43 days 23:31:11
Avg. CPU usage: ~15%
RAM usage: 14 % ( 872/5940 MB )

22.1 Legacy Series / Re: LAN traffic being randomly blocked by "Default deny rule", can't figure out why!

April 14, 2022, 11:22:48 PM

Thanks for your reply an apologies for my delayed response! You put me on the right track there talking about 'asymmetry'.

After failing to replicate the issue when connecting to devices on the other side of those two switches (i.e. on the 'LAN2' side physically speaking), but with their gateway set to LAN1's OPNsense router, I was able to rule out the switches and point the blame at the routing/Layer 3 stuff. Wireshark showed clear issues with a ton of retransmits, "Spurious retransmits", "Duplicate ACKs", which pointed toward routing issues.

There was a static route on OPNsense directing all traffic bound for 10.0.0.0/22 to the WAN interface of the pfSense box - but there was not an opposing static route on the pfSense one. You described it better than me, but it seems traffic going from LAN1>LAN2 was going through both(?) routers, yet the return traffic was going straight from device to device, skipping out the routers (or it might have just been skipping out the OPNsense but still routing via the pfSense, I'm unsure on this).

I am still vague on the cause and haven't fully understood it yet myself, but when I implemented a static route on the pfSense box directing traffic bound for 192.168.1.20 to 192.168.1.1 (the OPNsense router), the issue immediately disappeared when using 192.168.1.20 as my test source device. It will not let me create a static route for the whole of 192.168.0.0/23, as it gives the error that it conflicts with the pfSense's WAN interface IP.

I thought this topology, which removed double-NATting by routing between the subnets using static routes, was the ideal setup, but it seems this is actually a bizarre setup which has caused issues. I plan on rebuilding the LAN2 (home lab) network using OPNsense, and creating a double-NAT setup to fully segregate that network and do away with the static routes.

22.1 Legacy Series / LAN traffic being randomly blocked by "Default deny rule", can't figure out why!

April 12, 2022, 11:02:04 PM

Hi folks,

I have just deployed OPNsense as the gateway router for my home network, in place of an ISP provided router. All seems to be going pretty well, except for a developing problem with LAN to LAN traffic being blocked seemingly at random. This problem did not exist before the introduction of OPNsense in my LAN.

In my home network, I host a number of services behind a pfSense router, in a different subnet (10.0.0.0/22). OPNsense is configured with a static route to route this traffic to the WAN IP of the pfSense (192.168.1.11).

I can connect to these services just fine - the problem is keeping the connection! The firewall component of OPNsense is blocking packets destined for this subnet seemingly at random. This results in symptoms including RDP sessions regularly re-connecting, SSH sessions terminating after minute at best, and webapp use glitching or re-connecting.

Here is a screenshot showing these blocked packets in the log - https://imgea.uk/i/dvridjci.png
Here is a screenshot of the info view for one of these blocked packets - https://imgea.uk/i/temi64cs.png

That information points to Rule number 6, "Default deny rule" as the cause. Clicking the RID URL just leads to a 404, but I think I found the relevant rule in the Firewall Statistics view, screenshot here - https://imgea.uk/i/18ede2ma.png

I've created a diagram of how the LAN is structured, if it's of any use! - https://imgea.uk/i/iqjbcvx0.png

I just can't get my head around what might be causing this! I believe I've ruled out the pfSense box as the cause - the firewall log there is clear, and this issue only started happening with the introduction of OPNsense as my gateway router. I've heard "Out of state" traffic could cause this - I don't fully understand this, but I can say this appears to be replicable 100% of the time after initiating a new connection to a machine in the 10.0.0.0/22 subnet. Neither of the switches are doing anything funky such as port mirroring.

Could anybody here chuck any pointers my way for what could be causing this? Thank you

Pages1