Access website locally on different subnets

[dcol]

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.

[cookiemonster]

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.

[dcol]

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?

[Demusman]

Windows firewall or other software firewall?

[dcol]

Windows firewall is disabled on both servers.

[cookiemonster]

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?

[dcol]

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

[cookiemonster]

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.

[dcol]

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.

[cookiemonster]

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.

[Patrick M. Hausen]

A diagram of your networks with addresses and hostnames might help to solve the problem.

[dcol]

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.

[cookiemonster]

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.

[Koloa]

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.