Outbound NAT to access WebUI of DSL Modem

[dave79]

A 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 ?

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.

So the existing allow all isn't enough? Sorry I'm confused. What do I need to add as a firewall rule then?

P.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

Can you ping 8.8.8.8 from your LAN client?

Yes:

Code Select Expand

/ # 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


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?

192.168.100.0/24 isn't assigned to a second interface, but I do have bonding:

Code Select Expand

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


[dave79]

Maybe you shouldn't. WAN should be PPPoE in your case.

I can try this and see if it makes a difference.

[meyergru]

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.

[dave79]

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.

[Bob.Dig]

and I am sorry to have wasted your time.

Not only his. ;)

[dave79]

Not 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.

[dave79]

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.

[meyergru]

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 already.

[dave79]

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.

[Patrick M. Hausen]

This avoids having to reconfigure ~150 devices.

These devices do not use DHCP?

[dave79]

These 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.

[meyergru]

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

I object to the highlighted networks. Please read this first...

[dave79]

I object to the highlighted networks. Please read this first...

Thanks for the info, very helpful. I will make sure I factor this in when I change my setup.

[EricPerl]

as 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.

[dave79]

Really? 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.