I'm fairly sure this is either a NAT or routing question, but it's one that continually has me stumped.
The hardware is a Checkpoint Safe@Office firewall. The default mode of operation is that wired clients are on a 192.168.10.x network and wifi clients are on a 192.168.252.x, and that they are firewalled from each other.
One computer on the wired side is acting as a web server; serving the 'dev' subdomain of my business website. It is accessible from outside and inside and all works fine.
I however have a need for the wired and wifi networks to be able to talk to each other for other reasons. To do this; you can set the device into 'bridge mode' whereby both wired and wifi clients all end up with a 192.168.10.x IP address and can communicate freely.
Unfortunately, something about bridging in this way then seriously hampers the performance of the web server to the point where it's unusable from inside of the network - its still fine externally.
If I ping dev.mydomain.com from inside the network, it resolves to my public IP - and all my prior attempts (and googling) to get this configuration working suggests that because the request is outbound, then coming back into the network, it's "double natting" or something similar, causing the router to not be sure what to do with it.
Is there a way to solve this? I've found other people with the same problems (across different devices too) but haven't seen a solution that works.
Updated 31/03/2013:
I'm fairly convinced that the first answerer is on the right track with redirecting traffic using NAT rules.
At first, I thought the hardware wasn't working - but i've been able to confirm it by successfully redirecting all outbound web traffic from one device to nothingness, at it worked as expected.
So now the question is - what NAT rule(s) need to come into play to ensure traffic is property routed to the internal network?
I've attempted what seemed the most obvious:
WHEN: Source is Internal Networks, Destination is My Public IP and service is Web Server
THEN: Don't change the source, Change the Destination to My Internal Server IP and don't change the service.
This doesn't work, but I feel as though it should.
Update #2
I'm using the Microsoft Network Monitor to try and watch the packets of data to see if that offers up any insight.
Firstly, this raises a question about how the NAT translation works - because even with the rules in place, I see the request going out to dev.mydomain.com and inside the packet, the destination still reads as my public IP. Should translation actually CHANGE the destination, or is it just that it should silently redirect it?
Secondly, this also confirms the problem. If I look at a real website whilst capturing packets, the pattern looks pretty much as you would expect - firstly, a DNS lookup goes out and comes back, followed by a number of requests (presumably pertaining to all the standard files, JS, CSS etc as well as the HTML itself) each of which are almost immediately answered with packets of data.
If I look at my dev. subdomain; it's very one sided. With or without NAT rules, what I am seeing is that the request goes out and the initial responses come back, then the HTTP GET request goes out and is returned (and actually contains the HTML for the page) - but then nothing else. A bunch of requests go out for (I presume) the includes, and they are not answered. Eventually, they go out again, but still nothing comes back.
Could we be looking at an Apache problem rather than a router problem?
Update #3
So I created a basic HTML page with just a line of text and no included files and it works with or without NAT rules, sometimes instantly, sometimes it takes a few seconds - but it always works. I then included an image in the same way as they are included in the real pages, and it loaded - but always took between a few and tens of seconds to do it. Given that a real page will have a number of image requests as well as other files, it doesn't seem surprising that if they are all that slow, then this explains why the page times out. I'm no closer to figuring out why.