Menu

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 - AG_2023

#1
Hi,

I have setup Caddy exactly as described in OPNsense documentation.
I changed the OPNsense https port to 8443, checked the Disable web GUI redirect rule.
I have created the WAN and LAN rules for This firewall destination.
Enabled Caddy, supplied e-mail, Auto HTTPS is ON.
Domain is https://test.duckdns.org. Certificate is Auto HTTPS.
Handler: Domain is https://test.duckdns.org, Directive: reverse_proxy
Upstream:
Protocol: http://
Upstream domain: 192.168.250.162
Upstream port: 2283
Access list private_ipv4 created as per documentation and added to the domain access list

OPNsense runs on a dedicated hardware box, WAN and LAN interfaces only. Dynamic DNS is configured in OPNsense to use DuckDNS. I can do nslookup test.duckdns.org and it resolves to my WAN IP address, no problem. If I access https://test.duckdns.org from within my local network, it can access the server on 192.168.250.162:2283 without any issues. But when I access from internet, I get the error:

net::ERR_HTTP2_PROTOCOL_ERROR


The Caddy file is:

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# caddy_user=root

# Global Options
{
   log {
      output net unixgram//var/run/caddy/log.sock {
      }
      format json {
         time_format rfc3339
      }
   }

   servers {
      protocols h1 h2
   }

   email xyz@gmail.com
   grace_period 10s
   import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


test.duckdns.org {
   @c1ac6e21-c93d-461e-8546-246789993f33_testduckdnsorg {
      not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
   }
   handle @c1ac6e21-c93d-461e-8546-246789993f33_testduckdnsorg {
      abort
   }

   handle {
      reverse_proxy 192.168.250.162:2283 {
      }
   }
}

import /usr/local/etc/caddy/caddy.d/*.conf


I have done Google search but nothing. I have read all 21 pages of this thread but no matching issue. Caddy is getting certificate from Lets Encrypt. Any help would be appreciated.

OPNsense 25.1.9_2-amd647
os-caddy 2.0.1

Thanks,
Arun

Update: Issue resolved. The documentation is not good. It did not say when to stop creating reverse proxy. It went to configure access list for local access only. I did that and it blocked access from internet. I had to remove the access list from the domain and then reverse proxy started to work from internet. The documentation of Caddy needs to be revised as some options do not exist in OPNsense. It also needs to be made more descriptive to describe so many other options available.
#2
My network is dead simple. No VLAN, no guest network, just one LAN interface /24 subnet, no IPv6, one WAN interface. I have switched to Dnsmasq and Unbound combination as per the documentation example.

https://docs.opnsense.org/manual/dnsmasq.html#configuration-examples

See what happens...

Thanks for all the wonderful replies and clarification !!!
#3
Quote from: Patrick M. Hausen on May 14, 2025, 09:11:18 PMYes.

Both.

So do I need to configure both kea and Dnsmasq just to replace ISC DHCP?

Never mind, I found the answer in docs. Dnsmasq is recommended for small networks and is the most recent Opnsense offering. I will switch to using it as it seems to be a long term option.
#4
Is ISC DHCP going away? What is the replacement? kea or Dnsmasq?

Thanks
#5
The IPv6 Configuration Type for LAN is the problem. These are the options offered:

Static IPv6 <- I do not have a static IPv6 for LAN interface. I tried assigning some random IPv6 IP address and Matter over Thread devices stopped working.

DHCPv6 <- I do not have DHCPv6 setup for LAN interface, the IPv6 address is provided by the Thread Border Router. If I turn on DHCPv6 on LAN, the Matter over Thread devices stop working.

SLAAC <- I don't even know what this is
PPPoEv6 <- Don't have PPPoE, I have Verizon FIoS
6rd Tunnel <- No idea what this is
6to4 Tunnel <- No idea

Track Interface <- This is what I have setup currently. LAN interface tracks the WAN interface for IPv6. IPv6 is enabled on WAN interface even though not supported by ISP. If I disable IPv6 on WAN interface, this option gets disabled and Matter over Thread devices stop working. But enabling this option floods the logs with the error messages that I posted.

IPv6 is very confusing and I have spent lot of time trying to understand it, but no luck. So, I really need help.

Thanks...

#6
My ISP does not have IPv6. I just need to enable IPv6 on LAN interface so I can connect Matter over Thread smart home devices to the Thread Border Router built into Amazon Echo Gen4 device. What is the right way to do this? OPNsense version 24.7.11_2.

If I enable IPv6 on WAN and LAN interfaces, the log is full of hundreds of entries like:

2025-01-13T15:01:44-05:00 Notice kernel <7>cannot forward src fe80:2::f3ad:95c1:a7af:33c3, dst 2607:f8b0:4006:809::2003, nxt 6, rcvif igc1, outif igc0

Thanks
#7
24.1, 24.4 Legacy Series / kea DHCP problems
March 29, 2024, 02:52:04 AM
I migrated from ISC DHCP to kea and ran into following issues:

a) It is not possible to delete a lease. In ISC DHCP server, I could delete an inactive lease, but in kea there is no such provision in the GUI. As I was testing, I assigned a really long lease expiration time to a device (2 days) and now kea is not ready to release this lease. kea is not letting any other device use that IP address even though the original device has been assigned a different one. kea is just holding that IP address hostage.

b) It seems that the kea static leases do not get registered in Unbound DNS, only ISC DHCP static mappings do.

Any ideas how to resolve above issues?

Thanks...
#8
Thank you. This is exactly what I was looking for.
#9
Hi,

This issue has been happening ever since I started using Opnsense about a year ago. Sometimes, when I restart the Opnsense, it fails to get IP address from Verizon FiOS modem. It does not happen every time, but say one out of five. When that happens, I just restart Opnsense again and it gets the IP address. Till WAN_DHCP gets an IP address, all devices are offline so it is a bit of incovenience.

I was wondering if it is possible to write a script which can check for WAN_DHCP IP address. If it does not get an IP address after restart, then automatically restart Opnsense once again.

Thanks...
#10
Turns out that I had to supply a password to encrypt backups in the Google Drive setup section. I had set it up without supplying a password. Opnsense did not issue any warning/error so I assumed that password is optional. It is not optional.
#11
OPNsense 23.1.5_4-amd64

I have setup backup to Google drive. It is working and see backups in the folder designated for backup. I see files like config-1680152401.xml. But, when I look at the file details, all these backup XML files are 0 bytes. I downloaded the file and it still downloaded as 0 byte file. I do not see any error. The Test Google Drive works fine. Are these backup files supposed to be 0 bytes? If not, then how to fix?

Thanks...
#12
Embarrassed beyond limit. As I decided to tidy up the network cables, I noticed a cable connected wrongly from LAN switch to IOT access point. This was from before I started using the dedicated box for OPNsense. I thought I had removed it, but I did not. Once that cable was removed, all the IoT devices jumped back to IOT network and no more cross bleed of IP addresses. One cable caused so much headache...

So sorry to have wasted everyone's time. I need to pay more attention to setup.
#13
They are connecting to the right AP, but the more I think about it, the more I am inclined to say that it might be how the DHCP protocol works.

The DHCPDISCOVER from client is sent to all DHCP servers. Whoever responds first with DHCPOFFER, wins.

Now, it can be argued that LAN interface and IOT interface will never see each other's traffic, which  is true for wired networks, but not true if both interfaces have a dedicated WiFi access point. The client sends DHCPDISCOVER over WiFi and both access points respond with DHCPOFFER and the first one wins. Wired devices will never have this problem.

One way would be to create static DHCP mappings for IOT and LAN devices in their respective DHCP servers and then check the Deny Unknown Clients box. But this makes adding new devices a painful process. I will have to do more Google searches to see if there is a better/easier way.

Please let me know your thoughts or if there is any error in my access point logic.

Thanks...!!
#14
Hi,
I can definitely say that the IP addresses are getting assigned from the wrong DHCP server. The IOT devices are getting IP addresses from LAN and vice-versa. Not sure how to fix this. Any ideas?

Thanks...!!
#15
Thanks for confirming that FW rules and configuration is not causing it. I am pretty sure that DHCP assigned IP addresses are crossing over from LAN to IOT and vice-versa. However, let me monitor for one more day, in case these are some old leases. If I still continue to see them, then I will update this thread with more screen captures of what I am seeing in the WiFi routers attached devices section and leases in OPNSense.

Thank you so much for looking at my setup and replying back so quickly.