Doesn't look like the trace will help. You're getting Bell servers that won't respond to trace requests so it just times out. I can see your site and my tracert timed out too. Shame really because it's useful sometimes.

Interesting thing though, I plead ignorance seeing as it's at least 10 years since I played with any network stuff in anything remotely like a professional way. I had a quick squint at my owncloud server which is open to the internet. Turns out that the traceroute for that is totally different from my LAN to when I look at it from outside. From the LAN it goes to the router and from there straight back to the server, ie just two hops. Presumably the router is smart enough not to send a local request outside. But my router is a single (external) IP device for domestic use. Is the router you've been provided with handling a batch of external IP addresses? If so, does it make a difference whether you are on the same LAN as the web/file server, or whatever?

Aah, didn't see that last message until after mine.

I've worked out a couple of things to try. Complicating this is an .htaccess redirect from 80-443 (http-https).

I've set up a noip.com dynamic dns domain pointing at the WAN iP (I suspect this will wind up in the same bad place though)

or

I can NFS export the server's /var/www/html and point a virtualhost on another server and so see the WAN-facing *content* which is the main thing (always nice to confirm if it can be hit from the actual domain though)

A third option to consider is monkeying with another .htaccess rule to override the redirect for LAN requests but I dunno

A fourth option is to rejig the managed switch for DHCP, port forward the modem to that, and port forward the server from it.

Not liking any but worth a try, maybe.

Someone helpfully pointed out that these modems are 'internet for idiots,' which serve the market very well so why would they change that? (our old ISPs modem has no such issues, but it's more business oriented; Bell is late to the party)

That's sad. Is it going to be a problem for the business? 

Not really. The main thing is hitting the server from outside for all the WFH folks, it does that np. Also I mostly WFH ...

Verifying sftp access is my next priority.

Not 100% sure why the redirect to HTTPS is a problem (I have that on my server) but as I've contributed nothing useful so far, I shall leave you to continue enjoying yourself with network fun.
 

sftp over port 30 works.

If you're trying to use a consumer grade router/modem/firewall thing for vaguely business purposes, then all bets are off, really. There's a reason people pay more for business grade stuff: it let's you do the things you need to do. Thing like NATting  out of the router's external address and hairpinning back in again to the outbound address which is then NATted to an internal server (which gives the SecOps side of my career the heebies, by the way).

But anyway, do you have a DNS server running on the LAN, maybe on the router or a domain controller? You could try adding a custom DNS record for dewarstaging.com pointing to the LAN address of the server. That should make it work internally, while leaving any external DNS untouched.

Or do it with hosts files on all the internal PCs, if there aren't too many of them.

Also, are you using modem and router interchangeably here? Just checking, because they're different things, which I'm sure you know.

While I don't know much about American ISPs, I've heard they do some wierd shit. They're the reason things like frame-relay and ISDN were still included in Cisco Systems exams until fairly recently. Blocking port 22 inbound seems unecessary. It's not as if it's an uncommon port.

Edit: Basically, I recommend a Fortigate. Or a Palo Alto. Or a Checkpoint. Or almost anything business-oriented. Though probably not a Cisco.

Wish we had the SmartRG modem-router used by the previous ISP! It handled this hairpin stuff so transparently, I never even heard of it before, and didn't think to ask for it.

Coupla stories about that ISP: some time ago we needed to re-nat WAN port 80 to a different LAN IP, and I put in a ticket for the change. It transpired that in the course of changing ownership from local to multinational, they *lost* our router webmin login, and the one they had didn't work (note they had outsourced their support to India). Is that bad? Whelp, I was able to *guess* the login, and go in and update the config!

Now for the latest: a 'data hotel' subcontractor had a fire and explosion wiping out their optical fiber backbone (big-ass wire, whatever). In the middle of the worst blizzard we've seen in 30 years. It took them north of two days to restore service (by rerouting), and another two days to repair the cable. Force majeure, but my boss didn't like it one bit. So here we are ...

Suffice to say, configuring a 3d-party router for incoming ADSL (or whatever) is above my paygrade, and probably wild overkill for a *small* business?

Your idea about an internal, custom DNS record is plausible, maybe I can get my head around that. I *think* the aforementioned managed switch supports DNS somethings.

You the big dog!  :-D

What DNS servers does your DHCP scope give out? That should give you some clues as to where to look. If your PC is given an external DNS address, then you're out of luck, but if it's an internal address then whatever has that address may have the capability to hold custom records.

And if it doesn't, maybe it's time to set up your own DNS server so that you can do stuff like this. It's a fairly simple process (says the network engineer who's never done it before). If you're running an Active Directory domain then you should be able to add the DNS Server role to your domain controller, or look at BIND if you're a Linuxy person. And if you've got a domain controller, you could also add the DHCP server role to it, and control things yourself that way, without having to fight with a shit router.

I would say leave the managed switch to do switchy things, though. Let it worry about moving packets around and very little else. It's not a normal place for a DNS server or a DHCP server.

Configuring a router for ADSL shouldn't really be that much of a big thing (the ISP should be able to help, especially if you're paying business rates), but I'd also say that you should maybe have a look at the local IT firms and ask them how much it would cost. They do that kind of thing all the time and chances are it'll come in cheaper than paying you to spend much longer working it out, and if not cheaper then at least you'll come out of it with a simpler setup. If you find the right firm, they should be able to set it up for you and provide proper instructions on how to make the simpler changes without having to go back to them.

I've got a few things to try without messing around with DHCP or DNS. The server has to stay up and WAN-accessible 24/7. I've added a virtualhost on a port not open to the WAN, and doesn't have the redirect (which fortunately isn't in htaccess). Not able to really test any LAN stuff until I'm back in the office tomorrow. I have until the 'old' network cuts out (in a coupla weeks iirc) to sort this out as best I can. We'll see how it goes ...

The thing is, though, that you talk about "messing around with DHCP or DNS" when DNS is the exact tool you need to do what you need to do: have an external URL resolve to an internal IP address for devices on the LAN.

Talking about doing stuff with htaccess, redirects and virtualhosts sounds like the kind of fix that gets put in because it seemed sensible at the time, but ends up being a millstone round your or somebody elses neck for the next few years. It'll just be that thing that somebody put in in the past, but nobody ever has the time or inclination to take it apart and redo it properly.

Setting up an internal DNS server wouldn't have any effect on the accessibility of the web server from the internet (because your port-forwarding is already being done by IP address), but it would give you the simplest, most understandable way of accessing the server inside the LAN.

Basically, and I'm not trying to be nasty, because I know the kind of pressure that gets put on technical people in small companies, but you're bodging a fix rather than spending a little more time on it and getting a much better and more capable solution.

The 8081 patch (no relation) worked outta the box [*by LAN IP, not domain]  (fail)

I will revisit your sage advice in future!