Anywhere Access

[Douglas]

I confirm that throughout this topic my network is
(@) --- [InternetRouter] ----- (192.168.155.1) [CG] (10.0.10.254) ----- (10.0.10.11) [WindowsServer]

The Windows Server is on the internal LAN only, so has no connection to my internet router, other than as above thru’ CG.

As you advise not to use the DMZ, the internet router now forwards TCP 80 and 443 to 192.168.155.1

When in my internal network, https://10.0.10.11/Remote/ gives me the Windows Server Essentials Remote Web Access login screen I want.
When in the external network i.e. connected to my router’s wifi, http:// 192.168.155.1/remote gives me nothing and http:// 192.168.155.1:8090 gives me CG’s WebGUI.

CG is the DHCP server. Does CG have to be authenticated by the Windows Server DC?

[david]

No, there is no need to authenticate CG by the Windows Server DC in this configuration.

If your router forwards TCP 80 and 443 to 192.168.155.1, in turn your CG shoud forward those ports (NAT the destination IP) to 10.0.10.11. Did you implement your firewall rules by NATing the destination IP to 10.0.10.11 as I described before? As a reminder your firewall rules should look like this:

Code: Select all

firewall external raz
firewall external add InternetToWSHTTP allow tcp any rweb 10.0.10.11 80 nil 10.0.10.11 80
firewall external add InternetToWSHTTPS allow tcp any rweb 10.0.10.11 443 nil 10.0.10.11 443
apply

Best Regards,

[Douglas]

I did, as confirmed at 08:41 today "After applying the forwards you advise above, from the external network, 192.168.155.1:80 and https://192.168.155.1 still give me nothing, whilst 192.168.155.1:8090 is fine to get to the WebGUI."

Any advice on how to temporarily "relax" CG so that nmap port scan can be more informative?

[charles]

Hi David & Douglas,

Interesting discussion! Well, I see that the adopted solution by Douglas is to forward ports 80 and 443 to CG's external interface (IP 192.168.155.1) and not to the Windows Server (IP 10.0.10.11). In this case I think that if in your firewall rules you replace the destination IP 10.0.10.11 by any, it could resolve the issue. Therefore your firewall & NAT rules become as follows:

Code: Select all

firewall external add InternetToWSHTTP allow tcp any rweb any 80 nil 10.0.10.11 80
firewall external add InternetToWSHTTPS allow tcp any rweb any 443 nil 10.0.10.11 443

Those rules can be created from the CLI by typing the commands above or from the GUI by creating rules shown on the screenshot below:

cg-screenshot-firewall-dnat.png (45.38 KiB) Viewed 16507 times

Of course after having modified the configuration the apply command should be used to apply the new configuration. The apply operation can also be performed from the Web GUI at [GENERAL] > [Whole Configuration] > [Apply New Configuration] (or by clicking on the blinking blue down arrow in the top mini bar menu).

Actually a better solution would be to use the IP address 192.168.155.1 instead of any but a known bug in CacheGuard-OS EH 1.3.5 avoids the usage of a CG's real IP address as a destination IP in firewall rules.

Warm Regards,

[Douglas]

Many thanks Charles, that works

[charles]

I'm happy to hear that!

Now that you can configure CG as a firewall with NAT capabilities you can move forward and try the reverse proxy implementation (as suggested by David: option 2). But if you continue with the destination NAT based solution, think about replacing any by the IP address 192.168.155.1 once a patch to upgrade to EH-1.3.6 has been released.

To check the availability of a patch you can go to the Web GUI page [GENERAL] > [System Operations] > [Load OS Patch] and click on the "Check for Updates" link. You can also find our patches at https://www.cacheguard.net/cacheguard-patch.html. For more information regarding the upgrade and patching operation, you can consult the following documentation:
https://www.cacheguard.net/doc/command/system.html

All the Best,

[Douglas]

Thanks Charles. I look forward to the patch and will move on to option 2, with any questions arising, posted in a new topic.
So pleased we got past this hurdle.

[Douglas]

Please let me know when the patch is available as I'm probably sticking with option 1.
Option 2 seems complex and potentially replacing the security already implemented by the Windows Server or do I misunderstand?

[david]

No, CG does not replace any existing security feature but reinforce your security by adding a complementary security layer to your networks. Actually the reverse proxy implementation (option 2) is much easier to implement than the destination NAT solution as CG is cabled to be implemented like that. It's also a much more secure solution.

Maybe what seems to you a little bit complex is the TLS/SSL certificate part (for your HTTPS traffic). Are you using a self signed certificate or a certificate delivered by a CA (Certificate Authority) such as Symantec (ex Verisign), Thawte or Digicert?

[Douglas]

Thanks David, option 2 sounds worth pursuing. My Certificate is from CA GeoTrust.