"Recent posts
#61
General Discussion / Re: Cannot Access LAN network ...
Last post by meyergru - Today at 07:47:04 AMAd issue 1: You don't. First off, OpnSense's WAN is designed to not let anything in (w/r to the posting title: "it is not a bug, it is a feature!"). While you could technically allow this via firewall rules, eliminating outbound NAT or putting in port forwarding rules, it would not help, because all of your clients on the first router's LAN (192.168.2.0/24) only know their own subnet and a gateway (the first router). That in turn does not know of the existence of the 192.168.4.0/24 subnet behind OpnSense and with most consumer routers, you cannot put the necceaary route in there. In that situation, you would at least not use a "WAN" type interface at all, but a second "LAN", using OpnSense as a LAN/LAN router. This but does not save you from having to set up routes on your intermediate network 192.168.2.0/24.
Ad issue 2: With step 1 out of the way (which you probably cannot do on your specific equipment), you would have to have a port-forwarding rule in your first router to the PC on 192.168.4.0/24, which you probably cannot do, either.
You are stuck with a router-behind-router scenario, more complicated in that you expect some clients in the intermediate network 192.168.2.0/24 to also have access to 192.168.4.0/24 (instead of just having internet access, which they do).
Adding to this, you have an even more complicated setup than usual, because you have an additional pi-hole gateway. That is quite a zoo, that you will not be able to safely handle without networking skills. There is no step-by-step guide for your specific setup and it would not be safe to do so. If you expected your network to be "somewhat more safe" because you put an OpnSense in, you are mistaken. OpnSense is a product aimed at professional use, unlike most consumer router exquipment. It is also aimed at handling the networking as the sole router, preferably.
Basically, that is referenced here, point #4, but your setup has some additional quirks.
Ad issue 2: With step 1 out of the way (which you probably cannot do on your specific equipment), you would have to have a port-forwarding rule in your first router to the PC on 192.168.4.0/24, which you probably cannot do, either.
You are stuck with a router-behind-router scenario, more complicated in that you expect some clients in the intermediate network 192.168.2.0/24 to also have access to 192.168.4.0/24 (instead of just having internet access, which they do).
Adding to this, you have an even more complicated setup than usual, because you have an additional pi-hole gateway. That is quite a zoo, that you will not be able to safely handle without networking skills. There is no step-by-step guide for your specific setup and it would not be safe to do so. If you expected your network to be "somewhat more safe" because you put an OpnSense in, you are mistaken. OpnSense is a product aimed at professional use, unlike most consumer router exquipment. It is also aimed at handling the networking as the sole router, preferably.
Basically, that is referenced here, point #4, but your setup has some additional quirks.
#62
25.7, 25.10 Series / Re: Allow SSH for non-root use...
Last post by Ardentis - Today at 07:40:39 AMI figured out the problem. Turned out VERY simple, once I understood it. The non-root user that I created, with intent to use it to login via SSH, had login shell set to "Default". This means the user had this set behind the scenes: "/sbin/nologin".
Simply edit the user in opnsense GUI and set Login shell: to "/bin/sh". This then allows the ssh login to work.
I figured this out after I RTFM. https://docs.opnsense.org/manual/settingsmenu.html#secure-shell
That was simple.
Thanks
Simply edit the user in opnsense GUI and set Login shell: to "/bin/sh". This then allows the ssh login to work.
I figured this out after I RTFM. https://docs.opnsense.org/manual/settingsmenu.html#secure-shell
That was simple.
Thanks
#63
General Discussion / Re: Business Edition and Licen...
Last post by Monviech (Cedrik) - Today at 07:33:05 AMAs long as only one device is using the license you can use it on a new device.
#64
General Discussion / Cannot Access LAN network from...
Last post by kapee - Today at 07:20:01 AMI am a complete newbie on network so please pardon my ignorance here.
I installed OPNSense 25.7 and configured the defaults using the wizard. My OPNSense FW is behind my Router so the WAN Address is a private IP e.g. 192.168.2.106.
The gateway is 192.168.2.251 (PiHole for ad blocking). This also runs my OpenVPN (10.10.x.x) for friends to connect at times to my home network.
So the set up is as follows: ISP --> Internal Router (192.168.2.1: Gateway which has Pi Hole and OpenVPN running on the PiHole/OpenVPN) --> OpenSense FW (WAN: 192.168.2.106, LAN: 192.168.4.1)
The Opensense LAN 1 network built on 192.168.4.x so the LAN IP would be 192.168.4.1 192.168.4.X set with DHCP on so I can get many clients connected to this network
The machines connected to the LAN 1 (192.168.4.x) can connect to the internet (no Issue here)
Issue 1: The machines on Client 1 (192.168.2.x) cannot do remote desktop or ping any machine on LAN (192.168.4.x) network. How do I fix this?
Issue 2: Some of my friends connect via VPN to my network and they get a 10.10.X.X IP and can connect to the 192.168.2.x machines. I want to make sure that they can RDP to the 192.168.4.X machines
I don't understand NAT or Port Forwarding etc. so any steps would need to be completely watered down. I have tried steps mentioned here https://forum.opnsense.org/index.php?topic=16952.0 but it did not work for me unfortunately.
Any guidance would be highly appreciated
I installed OPNSense 25.7 and configured the defaults using the wizard. My OPNSense FW is behind my Router so the WAN Address is a private IP e.g. 192.168.2.106.
The gateway is 192.168.2.251 (PiHole for ad blocking). This also runs my OpenVPN (10.10.x.x) for friends to connect at times to my home network.
So the set up is as follows: ISP --> Internal Router (192.168.2.1: Gateway which has Pi Hole and OpenVPN running on the PiHole/OpenVPN) --> OpenSense FW (WAN: 192.168.2.106, LAN: 192.168.4.1)
The Opensense LAN 1 network built on 192.168.4.x so the LAN IP would be 192.168.4.1 192.168.4.X set with DHCP on so I can get many clients connected to this network
The machines connected to the LAN 1 (192.168.4.x) can connect to the internet (no Issue here)
Issue 1: The machines on Client 1 (192.168.2.x) cannot do remote desktop or ping any machine on LAN (192.168.4.x) network. How do I fix this?
Issue 2: Some of my friends connect via VPN to my network and they get a 10.10.X.X IP and can connect to the 192.168.2.x machines. I want to make sure that they can RDP to the 192.168.4.X machines
I don't understand NAT or Port Forwarding etc. so any steps would need to be completely watered down. I have tried steps mentioned here https://forum.opnsense.org/index.php?topic=16952.0 but it did not work for me unfortunately.
Any guidance would be highly appreciated
#65
25.7, 25.10 Series / Re: OPNcentral – Disable autom...
Last post by ews - Today at 06:21:00 AM #66
25.7, 25.10 Series / Re: Intermittent WAN Drops w/ ...
Last post by Kenjutso - Today at 03:57:05 AMIt looks like ntopng was definitely the root cause of my issues. I haven't had any problems since uninstalling ntopng. @letsief thanks for providing that github link, it seems to be the behavior I was experiencing. I'll look at adding it back again down the road, I don't think I was utilizing it at all since installing it so I'm fine without it for now.
#67
General Discussion / Re: Client IPv6 temporary addr...
Last post by OPNenthu - Today at 03:42:42 AMI think I can mark this as solved now since we identified the interactions causing this.
In the intervening time I have both migrated to Dnsmasq for RAs and also switched my primary OS from Windows 10 to Linux for other reasons. The temporary address generation is more reliable in this setup as well.
@meyergru thank you especially for your time spent on this, diagnosing and knowledge sharing. It's been educational and helpful.
In the intervening time I have both migrated to Dnsmasq for RAs and also switched my primary OS from Windows 10 to Linux for other reasons. The temporary address generation is more reliable in this setup as well.
@meyergru thank you especially for your time spent on this, diagnosing and knowledge sharing. It's been educational and helpful.
Code Select
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute br0
valid_lft 51379sec preferred_lft 51379sec
inet6 2601:xx:xxxx:xxxx:12bc:31e7:4009:dbf8/64 scope global temporary dynamic
valid_lft 86374sec preferred_lft 84986sec
inet6 2601:xx:xxxx:xxxx:2d05:986c:b8ac:af49/64 scope global temporary deprecated dynamic
valid_lft 86374sec preferred_lft 0sec
inet6 2601:xx:xxxx:xxxx:ce0e:4b9d:e4a5:5477/64 scope global temporary deprecated dynamic
valid_lft 86374sec preferred_lft 0sec
inet6 2601:xx:xxxx:xxxx:4c75:f80c:5f80:db72/64 scope global temporary deprecated dynamic
valid_lft 86374sec preferred_lft 0sec
inet6 2601:xx:xxxx:xxxx:604:6861:6145:ff83/64 scope global temporary deprecated dynamic
valid_lft 86374sec preferred_lft 0sec
inet6 2601:xx:xxxx:xxxx:8af4:2fd2:493f:3684/64 scope global temporary deprecated dynamic
valid_lft 86374sec preferred_lft 0sec
inet6 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:9dca/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86374sec preferred_lft 86374sec
inet6 fe80::dc69:xxxx:xxxx:xxxx/64 scope link noprefixroute
valid_lft forever preferred_lft forever
#68
25.7, 25.10 Series / Re: Intermittent WAN Drops w/ ...
Last post by letsief - October 21, 2025, 11:24:02 PMI switched ntopng to only run on the LAN interface, so the WAN doesn't end up in promiscuous mode. It seems to be working for now. We'll see if it creates other problems, though, on the LAN side.
#69
25.7, 25.10 Series / Revisiting "Firewall: Diagnost...
Last post by pfry - October 21, 2025, 10:31:54 PMA search on this topic came up with a number of threads, but no resolution (that I saw offhand). I can induce this behavior myself by adding or deleting rules; this does not seem to cover all of the posted cases (it persists through the life of the session only). I really have one question: Are these dialogs scheduled for rewrite/revision? I don't see anything obvious in the roadmap; I didn't dig through github. I won't bother poking at them if they're going to be obsolete soon (or if I missed a resolution).
#70
25.7, 25.10 Series / Re: Intermittent WAN Drops w/ ...
Last post by letsief - October 21, 2025, 10:17:26 PMThings were running stable after I disabled ntopng. Turning it back on very quickly broke the ipv4 stack again.
It seems to be related to ntopng putting the interface in promiscuous mode.
https://github.com/opnsense/core/issues/7478
Not sure if there is any way to work around this problem.
It seems to be related to ntopng putting the interface in promiscuous mode.
https://github.com/opnsense/core/issues/7478
Not sure if there is any way to work around this problem.
