I did some searching around and could not find an answer to this.
I have a website on 192.168.1.101 and can access it on that server and remotely, but cannot access it from other subnets on the same network. ie, 192.168.100.5. I have NAT Reflection turned on. I have another webserver @ 192.168.20.5 that I can get to from any subnet or remotely. Both servers use IIS 10 and have their own WAN IP.
I don't have any special rules for the server that works. Any Help would be appreciated.
Thanks for looking.
technically 192.168.1.101 and 192.168.100.5 are in different networks, subnets of 192.168.x.y . Unless you have set them to static ips incorrectly, you have two subnets 192.168.1.x/24 and 192.168.100.x/24. These two need routing between them, that's where you normally have a router, routing between the two. And firewalls to segregate. What follows is that you need a firewall rule in the incoming interface of the one being sent from allowing the traffic.
Since you have a device on yet another subnet 192.168.20.x/24 that works, a comparison of the rules should indicate what you're missing.
Rules between the two in OPNsense are identical. Both are HTTPS connections and the IIS bindings are also identical. Both servers have a NIC going to the same subnet as the Local LAN @ 192.168.100.x. These are tested as I can get to either servers files. I actually have two different websites on the server that works. Both websites are accessible locally from that server. The LAN rules are the simple default rules.
Any ideas?
Windows firewall or other software firewall?
Windows firewall is disabled on both servers.
Ah OK , sorry I misread the original post.
I take it you have verified there is a different way you are accessing the files in that case, how is that done, on a different ip?
On the server that I cannot locally access websites, I can access the files via SMB or remote in and can also ping the local and WAN IP's. The system is fully accessible locally except for the websites. I looked close at IIS and see nothing obvious there.
I can also Browse the Website within IIS. Just not on any computer on a different Local subnet
Are you sure you're accessing it by lan ip and not by website url? Sounds like it could be a webserver-side problem.
Browsing the site from IIS tells you only that the site is up but it normally uses localhost by default and/or the binding ip. So not a network check in itself, but good to check.
I can use the URL https://<sitename> in a browser on the server or remotely and it works. Just not on any other local subnet in OPNsense.
I even tried toggling NAT Reflection in the NAT rule.
Right. Presumably if you use the lan address you get to it? If so, then it needs a host over-ride in your local dns resolver.
If not, I suggest a traceroute and/or packet capture.
A diagram of your networks with addresses and hostnames might help to solve the problem.
Using the LAN address does not work because of the https requirement. When I browse in IIS it resolves to the sitename. There are no overrides in DNS Unbound for my server on 192.168.20.5, and that seems to work ok locally. I did try to add a hosts entry for it. no go.
I can do a diagram if I see an example of how that is to be presented.
It would help but one thing I get my teams to do in cases like this is to create a simple virtual directory under the same root, with just a .txt file within the filesystem, and you can bind both 443 and 80 just for testing.
This may not help you, but, I ran into this issue on my nascent OPNsense setup within my LAN as well. A lot of tcpdumping later I ended up resolving the issue with a split DNS configuration. Essentially, the OPNsense device was replying to packets with a different IP address on the IMAPS/HTTPS server than the client device was requesting them from. I couldn't get the NAT reflection to work as I was expecting, and the split DNS solution was the most simple/elegant way to resolve it in my case.
Would strongly recommend tcpdump on the client and server - see what arrives, see what replies, and with what IPs, it may provide a clue.