I have an OPNsense with the following setup:
LAN Network: 192.168.71.0/24
WAN Side: Zyxel DSL modem, PPPoE connection handled by OPNsense
DSL Modem: IP address 192.168.100.1
I want to access the WebUI of the DSL modem from my LAN, which has the IP address 192.168.100.1. To achieve this, I created an additional interface on the OPNsense on the same physical Ethernet port and assigned the IP address 192.168.100.2 to the OPNsense.
Steps Taken So Far:
Interface Configuration:
An interface named DSL-Modemconf with the IP address 192.168.100.2/24 was created.
Firewall Rules:
An any-to-any rule is configured on the LAN interface.
Outbound NAT Rule:
An outbound NAT rule was configured to translate traffic from 192.168.71.0/24 to the IP address 192.168.100.1 to the IP address 192.168.100.2.
Routing Table:
The routing table shows the route 192.168.100.0/24 on the interface DSL-Modemconf.
Ping Tests:
Ping from the OPNsense with the source IP 192.168.100.2 works.
Ping from the OPNsense with the source IP 192.168.71.1 does not work.
Firewall Logs:
No blocked packets in the firewall logs.
ARP Table:
The ARP entry for 192.168.100.1 shows the correct MAC address of the modem.
NAT Reflection:
Reflection for port forwards, Reflection for 1:1, and Automatic outbound NAT for Reflection have been enabled.
Question: Why can't I access the WebUI of the DSL modem from my LAN, even though the NAT rule and firewall rules are correctly configured and no packets are being blocked?
I recently switched from pfSense to OPNsense and had this exact setup working with pfSense, and now I'm at a loss.
Quote from: techvic on March 22, 2025, 10:20:52 AMAn any-to-any rule is configured on the LAN interface.
No firewall rules and no blocked traffic on the DSL-Modemconf interface?
Maybe [Tutorial] Bridged Modem Access Guide (https://forum.opnsense.org/index.php?topic=33497.0) is of help?
The traffic is always initiated from the LAN-side, so it shouldn't require a rule on the DSL-Modemconf-Interface, however, I already put an any-rule there too for testing
QuoteAn outbound NAT rule was configured to translate traffic from 192.168.71.0/24 to the IP address 192.168.100.1 to the IP address 192.168.100.2
You configured an outbound NAT rule on the DSL-Modemconf-Interface interface with source LAN subnet, destination 192.168.100.0/24 and Translation/target set to Interface address? And set the oubound NAT mode to 'Hybrid ...'? Then it really should work, yes.
A package capture on the DSL-Modemconf-Interface could give some inside.
damn, I mistakenly had the NAT outbound rule on the LAN interface. I checked the rule a thousand times and never noticed that. Thanks for you hint!
Glad it got sorted.
I am trying to do the same thing and I have fallen at the first hurdle.
@techvic Could you explain how you added the new interface? Do you mean a virtual IP? I checked the assignments page, but I am not able to add another WAN assignment:
(https://i.ibb.co/SwcY89qZ/assignments.png)
I would very much appreciate it if you could add some screenshots of the settings you changed so I can replicate :)
It should be noted that I am not using OPNsense hardware, I am not sure if this is the reason?
Thanks
Whether you need an interface or a VIP depends on how your WAN connection is set up.
- If you have DHCP on WAN, you will need a a VIP.
- If you have PPPoE over VLAN, then your ISP modem will be accessible on the parent interface of your PPPoE WAN interface and you can configure it with an IP. This seems to be the case for @techvic.
- If you have PPPoE directly on the ethernet interface without a VLAN, you should also need a VIP - but IDK if that really works.
In each case, you will need outbound NAT rules on the modem interface to use an address for the modem's IP range.
Thanks for the help. My WAN IP is assigned by DHCP in OPNsense.
So far I have done this:
Virtual IP:
(https://i.ibb.co/DHzs4m80/image-1.png)
Outbound NAT:
(https://i.ibb.co/b5p4TFt7/image-2.png)
LAN Firewall Rule:
(https://i.ibb.co/Z1cqvbkv/image-3.png)
I am still unable to ping or reach the modem though, what am I doing wrong?
(apologies, the last image is a bit naff because I had to zoom right out in the browser to take a screenshot)
Looks right apart from one thing: The "Translation / target" IP must not be the interface address (which would be you WAN IP), but the VIP, which is the only one your modem could successfully reply to.
Oh, and BTW: see this remark (https://forum.opnsense.org/index.php?msg=181474).
P.S.: Do not "Block private networks" on the WAN interface.
Quote from: dave79 on May 03, 2025, 02:36:13 PMMy WAN IP is assigned by DHCP in OPNsense.
Then you don't have to do anything for reaching your modem. Show all your WAN-rules, maybe you are blocking private IPs.
I have corrected the translation target:
(https://i.ibb.co/mVhnh2Wv/translation-target.png)
Block private networks on WAN was indeed checked, but now unchecked.
Still no access so here are my WAN firewall rules:
(https://i.ibb.co/cqHJmwW/WAN-firewall.png)
Edit: Not sure why but firewall image seems to have been reduced in size, here's a direct link: https://ibb.co/YgM2rX5
In terms of the interface being available, I didn't think of that but I am fairly sure it's still active as the ISP says it's still possible to login to the web UI to put back in router mode as opposed to resetting it. They say the IP is 192.168.0.1 in router mode and 192.168.100.1 in modem mode.
Edit2: Just in case I'm trying to flog a dead horse here, I double checked that the interface is available by connecting a laptop, and I can get to the web UI on 192.168.100.1.
Also, it might be worth mentioning here for anyone else in my situation, I have the Virgin Media SuperHub 5, when in modem mode it must be the last thing turned on as it locks the MAC of the device on the 2.5G port 4 (the only working port). So if you change a device like plugging in a laptop you must connect it powered on and reboot the hub. You can't hot swap.
IDK if that translation target is actually correct. It should be /32, but it is easier to select the line with your VIP definition - the entry will look differently.
You should probably try first to ping the IP from OpnSense itself before trying to NAT from your LAN. I had a problem with that because of an outbound block rule for RFC1918 giving "ping: sendto: Permission denied".
Ok, I changed the subnet to /32 in the VIP config, then selected the entry in the outbound NAT page = no ping on 100.1 or 100.2.
Then I disabled the outbound NAT rule and tried again = no ping on 100.1 or 100.2
Then I deleted the VIP (bearing in mind I have now unchecked blocked private networks in WAN) = no ping on 100.1.
Surely this should be accessible somehow if it's available when connecting just a laptop?
You misunderstood: Not /32 in the VIP config - in the NAT translation target. Outbound NAT is translating a full network (LAN) to one specific IP (/32), not to a network (/24). And that can be achieved by using the specific VIP entry in the dropdown for the NAT translation target, instead of specifying it directly.
However, just as I said: First get the VIP working locally on the WAN like described in the guide. It should result in a 192.168.100.2/24 address on your WAN. This would look as follows:
# ifconfig
...
igc3: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802728<VLAN_MTU,JUMBO_MTU,TSO4,TSO6,LRO,WOL_MAGIC,HWSTATS,MEXTPG>
ether 00:44:69:54:6d:88
inet 100.66.90.157 netmask 0xffff0000 broadcast 100.66.255.255
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
...
Then try to ping 192.168.100.1. It should work without NAT from OpnSense, unless your firewall blocks it. Then add the NAT rules to make the modem accessible from your LAN.
Quote from: dave79 on May 04, 2025, 09:14:10 AMThey say the IP is 192.168.0.1 in router mode and 192.168.100.1 in modem mode.
What is your WAN-Address in OPNsense?
@meyergru Ok, let me start this again. With the VIP added, I logged into OPNsense and I can ping the modem:
root@OPNsense:~ # ping -c 10 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=4.667 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.575 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=5.996 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=4.854 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=4.588 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=4.569 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=4.573 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=4.535 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=64 time=4.606 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=64 time=4.536 ms
--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.535/4.750/5.996/0.425 ms
I checked ifconfig:
em1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 00:1f:x:x:x:x
inet 82.x.x.x netmask 0xfffffc00 broadcast 82.x.x.x
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::x:x:x:ec81%em1 prefixlen 64 scopeid 0x2
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Then I added the outbound NAT:
(https://i.ibb.co/Fqqr9HqF/outbound-nat.png)
But I am still unable to ping 192.168.100.1 from a machine on LAN or access the web UI. So I guess this is a firewall problem?
@Bob.Dig When port 4 of the modem is connected to OPNsense's WAN port, it shows my public IP, but if I unplug it (after setting up the VIP) it shows 192.168.100.2
Do you have a rule on LAN that allows this traffic? If yes, does that rule explicitly set a gateway?
Yes I have a rule and no, the gateway is set as default:
(https://i.ibb.co/VhQqMyH/firewall.png)
Apart from default, the options I have in the drop down are:
(https://i.ibb.co/rfcvF84x/gateway.png)
I tried WAN and WAN - IP but there was no change. Have I messed something else up?
Destination: 192.168.100.0/24 (should also be an automatic alias "DSL net" or whatever you named that interface) or 192.168.100.1/32 or as a host alias without a prefix length.
Also, why do you need a rule at all? Don't you allow destination "any" on the LAN interface, anyway?
Quote from: dave79 on May 04, 2025, 07:55:41 PMHave I messed something else up?
I say yes because usually it works out of the box. So show all your LAN and Floating rules and maybe Outound-NAT if you changed something there.
Quote from: Patrick M. Hausen on May 04, 2025, 08:01:42 PMDon't you allow destination "any" on the LAN interface, anyway?
Yes, I only ever added one rule to LAN before now.
Quote from: Bob.Dig on May 04, 2025, 08:02:37 PMSo show all your LAN and Floating rules and maybe Outound-NAT if you changed something there.
Rules: https://ibb.co/Z1GRdWrY
Outbound NAT: https://ibb.co/S4BbN9r2
Are you using PPPoE or DHCP for your Internet? But at this point, I give up anyways.
Quote from: Bob.Dig on May 04, 2025, 08:02:37 PMusually it works out of the box
I have to correct myself, for a cable-modem it usually works out of the box but here the case is different, sry.
I am using DHCP on the WAN port.
In some the posts above I think I have said modem, but it's technically a router in modem mode.
Ok, thank you for taking the time to troubleshoot this, I really appreciate it.
Out of interest, I have seen some people say that double NATing isn't usually an issue - even for torrents and VPNs etc - could this be a possible workaround? Put it back in router mode, disable wifi then do it that way? The reason I am so keen to get this working is that I am having some latency issues at the moment, and I really need to be able to access the router to diagnose.
Given the penultimate rule (allow all), you don't need another FW rule. You should enable logging on that rule though (especially while troubleshooting).
VIP and Outbound NAT should be sufficient (hopefully force-gateway is not going to interfere).
At this point, you should check you FW live view filtered to dst is MODEM_IP
You should see in on LAN, out on WAN (you may need to visit FW > Settings > Advanced to tweak logging of default rules) as you try to access.
If you do see both green, check source and destination are as expected (on WAN side, source should be VIP).
If you don't, report with screenshot.
If you did, and it still doesn't work from the browser, you need to do a packet capture (LAN + WAN, filter to modem IP). Download and attach the results.
The only thing I can imagine here that still causes problems would be an outbound firewall rule that blocks LAN IPs from ever leaving the WAN interface. I had this in place because my ISP reacts by cutting the connection if he sees outbound non-routeable IPs. I had to preceed that rule by one allowing the specific modem traffic.
Ok, just to make sure I didn't mess something up (which is not out the realms of possibility as this is totally out of my comfort zone) I restored from a snap before I even posted here. First I checked "Log packets that are handled by this rule" on the allow any LAN rule.
I pinged 192.168.100.1 from OPNsense and this is what I see: https://i.imgur.com/660OonZ.png
Unless I am wrong, this looks like the connection is allowed out of LAN in the logs?
The ping looks like this:
root@OPNsense:~ # ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^C
--- 192.168.100.1 ping statistics ---
11 packets transmitted, 0 packets received, 100.0% packet loss
Then I added the VIP (IP Alias, WAN, 192.168.100.2/24 - nothing else) and looked again: https://i.ibb.co/hFQNhdm0/wan.png
Shouldn't the LAN also be listed in the logs once the VIP is added?
This time the ping doesn't time out (from OPNsense again):
root@OPNsense:~ # ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=4.617 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.555 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=4.469 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=4.502 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=4.565 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=4.554 ms
^C
--- 192.168.100.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
Now I added the outbound NAT: https://i.ibb.co/Fqqr9HqF/outbound-nat.png (but logging was checked too, this is a screenshot from earlier)
Firewall logs: https://i.ibb.co/rGLZx6jw/nat-logs.png
Ping from OPNsense:
root@OPNsense:~ # ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=6.595 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=2.918 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=2.918 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=3.008 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=2.870 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=2.950 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=2.897 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=2.916 ms
^C
--- 192.168.100.1 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.870/3.384/6.595/1.214 ms
Ping from machine on LAN:
/ # ping -c 4 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
From 192.168.1.10 icmp_seq=2 Destination Host Unreachable
From 192.168.1.10 icmp_seq=3 Destination Host Unreachable
From 192.168.1.10 icmp_seq=4 Destination Host Unreachable
--- 192.168.100.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3068ms
pipe 3
When I ping from the LAN machine, there is no additional entries in the firewall log.. also not sure why the ping shows it's trying to ping the LAN machine itself.. something is very wrong.
Quote from: dave79 on May 05, 2025, 10:55:58 AMUnless I am wrong, this looks like the connection is allowed out of LAN in the logs?
No, it just shows that nobody answers. Since you did not define a 196.168.100.0/24 net yet, this was expected, but tells nothing at all.
Quote from: dave79 on May 05, 2025, 10:55:58 AMThen I added the VIP (IP Alias, WAN, 192.168.100.2/24 - nothing else) and looked again: https://i.ibb.co/hFQNhdm0/wan.png
Shouldn't the LAN also be listed in the logs once the VIP is added?
This time the ping doesn't time out (from OPNsense again):
root@OPNsense:~ # ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=4.617 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.555 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=4.469 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=4.502 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=4.565 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=4.554 ms
^C
--- 192.168.100.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
No, only the main IP/Network is listed in the GUI. You can see additional VIPs in the CLI via "ifconfig".
Quote from: dave79 on May 05, 2025, 10:55:58 AMNow I added the outbound NAT: https://i.ibb.co/Fqqr9HqF/outbound-nat.png (but logging was checked too, this is a screenshot from earlier)
Firewall logs: https://i.ibb.co/rGLZx6jw/logs.png
Ping from OPNsense:
root@OPNsense:~ # ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=6.595 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=2.918 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=2.918 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=3.008 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=2.870 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=2.950 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=2.897 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=2.916 ms
^C
--- 192.168.100.1 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.870/3.384/6.595/1.214 ms
Ping from machine on LAN:
/ # ping -c 4 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
From 192.168.1.10 icmp_seq=2 Destination Host Unreachable
From 192.168.1.10 icmp_seq=3 Destination Host Unreachable
From 192.168.1.10 icmp_seq=4 Destination Host Unreachable
--- 192.168.100.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3068ms
pipe 3
When I ping from the LAN machine, there is no additional entries in the firewall log.. also not sure why the ping shows it's trying to ping the LAN machine itself.. something is very wrong.
As told, for getting to this IP from the LAN, you need:
1. A working network connection from OpnSense to the modem (which you have). This includes a route to the 192.168.100.0/24 network.
2. A outbound NAT rule from the LAN to the WAN. This is to assure that the sender address is your VIP, because your modem does not know the route back to your LAN, it can only address IPs in the 192.168.100.0/24 network.
3. A firewall rule allowing the traffic from your LAN to the modem. You do not need a reverse rule, since the responses are allowed automatically.
You seem to have that all, yet it does not work. Proof for the first step being carried out correctly is given by the working ping, so it seems that the other two steps - which seem correct, too - fail somehow.
P.S.: How did you configure your LAN client? I assume that OpnSense's LAN IP is the gateway? Because if it is not, then obviously, it will not be reached for IPs outside the LAN network... Can you ping 8.8.8.8 from your LAN client? Or did you assign a 192.168.100.0/24 IP on a second network card? Essentially: Does the routing for the target network from your LAN client work at all?
Quote from: dave79 on May 04, 2025, 11:53:45 PMI am using DHCP on the WAN port.
Maybe you shouldn't. WAN should be PPPoE in your case.
Quote from: meyergru on May 05, 2025, 12:22:25 PMA outbound NAT rule from the LAN to the WAN.
Sorry to be dumb here, but haven't I done this with: https://imgur.com/mZ2j0rw.png ?
Quote from: meyergru on May 05, 2025, 12:22:25 PMA firewall rule allowing the traffic from your LAN to the modem. You do not need a reverse rule, since the responses are allowed automatically.
So the existing allow all isn't enough? Sorry I'm confused. What do I need to add as a firewall rule then?
Quote from: meyergru on May 05, 2025, 12:22:25 PMP.S.: How did you configure your LAN client? I assume that OpnSense's LAN IP is the gateway?
Yes, OPNsense is the gateway 192.168.0.1
Quote from: meyergru on May 05, 2025, 12:22:25 PMCan you ping 8.8.8.8 from your LAN client?
Yes:
/ # ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=21.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=19.6 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.628/20.460/21.197/0.644 ms
Quote from: meyergru on May 05, 2025, 12:22:25 PMOr did you assign a 192.168.100.0/24 IP on a second network card? Essentially: Does the routing for the target network from your LAN client work at all?
192.168.100.0/24 isn't assigned to a second interface, but I do have bonding:
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 192.168.1.10 netmask 255.255.0.0 broadcast 192.168.255.255
inet6 fe80::x:x:x:x prefixlen 64 scopeid 0x20<link>
ether de:d0:x:x:x:x txqueuelen 1000 (Ethernet)
RX packets 468115983 bytes 463457888920 (463.4 GB)
RX errors 97642 dropped 166624 overruns 0 frame 74250
TX packets 345940032 bytes 233493783457 (233.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Quote from: Bob.Dig on May 05, 2025, 12:56:49 PMMaybe you shouldn't. WAN should be PPPoE in your case.
I can try this and see if it makes a difference.
And there we are (quoting from your bond0 interface configuration):
"inet 192.168.1.10 netmask 255.255.0.0 broadcast 192.168.255.255", which essentially is 192.168.0.0/16.
That netmask includes your VIP network of 192.168.100.0/24. Thus, the packets never make it out the WAN interface, they are not even routed over OpnSense at all, no matter what you do. This is the problem - basic networking 101.
Ahh ok, thanks. I'll have to see if I can reconfigure everything on /24 then try again. Thanks for persevering and I am sorry to have wasted your time.
Quote from: dave79 on May 05, 2025, 03:27:07 PMand I am sorry to have wasted your time.
Not only his. ;)
Quote from: Bob.Dig on May 05, 2025, 06:22:01 PMNot only his. ;)
Sorry, I was referring to everyone who has chimed in, but I am sorry to have wasted your time also. Thanks for trying to help.
Having kicked myself for this a lot over the course of the last few hours, I have been reading a lot about networking subnets. If anyone is interested or finds themself in the same situation in future: I have changed my subnet to /19 which only covers 192.168.0.0 - 192.168.31.255. This avoids having to reconfigure ~150 devices. I can now access the modem UI without any VIP or outbound NAT.
Once again I would like to apologise to everyone who spent time on this.
The conventional way to solve this is to have /24 ranges from 192.168/16, which gives you up to 254 IPs per range. If you have more IPs, you should better use VLANs, not only to separate them into security zones, but also to avoid broadcasts to take up a big portion of your network traffic. A /24 subnet is also easier to deal with for humans, because the first 3 octets always stay the same.
If you have valid reasons to put a lot devices into the same subnet, you could use 172.16/12 or a subnet thereof. Even 10/8 is most often split up in enterprise contexts.
Failure to do this in the usual way may also be one of the reasons why nobody got this earlier: Seeing that 192.168.100.2/24, we simply assumed that you always use /24 for your other ranges, too. I only caught attention when you showed your actual configuration, although I suspected routing problems here (https://forum.opnsense.org/index.php?msg=236468) already.
Thank you for the advice. I will treat my current solution as a temporary fix and have a think about which of those I would be best using.
Quote from: dave79 on May 06, 2025, 12:56:41 AMThis avoids having to reconfigure ~150 devices.
These devices do not use DHCP?
Quote from: Patrick M. Hausen on May 06, 2025, 09:10:54 AMThese devices do not use DHCP?
Some yes, like phones, watches etc. but for most I define static leases as the vast majority of them are IoT devices that require static addresses. Unfortunately not all of them have mDNS. So it's not so trivial to just change everything. It's at least a whole days work with a non-working house. The reason I originally chose 192.168.0.0/16 is because I thought it would be tidier and easier to organise to have it like this:
192.168.0.x - routers and switches
192.168.1.x - servers
192.168.2.x - bulbs
192.168.3.x - plugs
192.168.4.x - sensors
192.168.5.x - audio and visual
192.168.6.x - cameras
etc
Well, you get the point. Obviously knowing what I know now, I would have done things differently.
Quote from: dave79 on May 06, 2025, 12:11:49 PM192.168.0.x - routers and switches
192.168.1.x - servers
192.168.2.x - bulbs
192.168.3.x - plugs
192.168.4.x - sensors
192.168.5.x - audio and visual
192.168.6.x - cameras
etc
I object to the highlighted networks. Please read this (https://forum.opnsense.org/index.php?topic=47099.0) first...
Quote from: meyergru on May 06, 2025, 01:55:06 PMI object to the highlighted networks. Please read this (https://forum.opnsense.org/index.php?topic=47099.0) first...
Thanks for the info, very helpful. I will make sure I factor this in when I change my setup.
Quoteas the vast majority of them are IoT devices that require static addresses.
Really? Example?
I don't know that I own one that supports that. Requiring it seems like such a poor design decision.
Quote from: EricPerl on May 06, 2025, 04:48:08 PMReally? Example?
I don't know that I own one that supports that. Requiring it seems like such a poor design decision.
Sorry, I mean with my setup. The IoT device itself can use DHCP - what I mean is other things in my home automation expect them to be static.
A few things off the top of my head:
ESP devices depending on firmware, there's no mDNS due to limited flash - I have a LOT of these. One good example is Hyperion which connects to an ESP8266 to control LEDs. Some of my smart plugs have a fairly rubbish integration with my home automation as well and need to be static because it always expects them to be in the same place. The Hue hub is a good example too - if the IP changes, you have to manually reload the config after specifying the new IP for it to be picked up again. I also have a lot of automation scripting that would require altering each time if the IP changes.
Edit: Tasmota firmware has no mDNS either.
Hint: a static DHCP lease in OPNsense can register a DNS name which can then be used in Home Assistant or similar.
Quote from: Patrick M. Hausen on May 06, 2025, 05:23:03 PMHint: a static DHCP lease in OPNsense can register a DNS name which can then be used in Home Assistant or similar.
Thanks!