Like all firewalls that have ‘web management’ the default ports are 80 and 443 for insecure and secure management. IF you have secure (https) management on the outside interface of your firewall on the normal TCP port of 443. Then you can’t use the same interface to terminal SSL–VPNs. So you will need to change the FortiGate Management Port.
You can set SSL-VPN to use a different port of course, but for your remote workers who may be in hotels, or in locations where only web (port 80) and secure web/HTTP (port 443) are only allowed that’s going to be a problem.
The lesser of the two evils is to change the secure web management port to something that is not 443!
Changing the Fortigate Management Port (HTTPS)
Note: I’m talking about changing the TCP port, NOT the physical management port, if that’s what you are trying to do, then you simply enable that on the INTERFACE on the firewall like so;
FortiGate Change Management Port via CLI
Firstly to find out/check the port that https is currently configured on use;
[box]
show full | grep admin-sport
[/box]
Then to change the port number (in this case to 4433) use;
[box]
config system global
set admin-sport 4433
[/box]
FortiGate Change Management Port via GUI
System > Settings > Administration Settings > HTTPS Port.
Change the port number accordingly > Apply >After a while it will try and reconnect and probably fail, (that’s OK).
Reconnect to the firewall using https://{IP-or-Hostname}:{Port-Number}
Related Articles, References, Credits, or External Links
Given the amount of deployments I do, it’s surprising that I don’t use KMS more often. Like most technical types, I find a way that works for me, and that’s the way I do things from then on. However these last few weeks I’ve been putting in a new infrastructure for a local secondary school. Their internet access is through a proxy server, that refuses to let Windows activation work. Unfortunately the “Administrators” of this proxy server were not disposed to give me any help, or let me anywhere near it, to fix it.
So after activating a dozen servers over the phone, I decided enough was enough “I’m putting in a KMS Server!”
I’m deploying KMS on Windows Server 2008 R2, and it is for the licensing and activation of Serer 2008 R2 and Windows 7. I will also add in the licensing KMS mechanism for Office 2010 as well.
Note: If you are using Server 2003 it will need SP1 (at least) and this update.
Solution
To be honest it’s more difficult to find out how to deploy a KMS server, than it actually is to do. I’ve gone into a fair bit of detail below but most of you will simply need to follow steps 1-4 (immediately below). In addition, after that I’ve outlined how to deploy KMS from command line. Then how to test it, and finally how to add Microsoft Office 2010 Licenses to the KMS Server.
Install Microsoft Windows 2008 R2 Key Management Service (EASY)
1. The most difficult part is locating your KMS Key! If you have a Microsoft License agreement, log into the the Microsoft Volume License Service Center, and retrieve the KMS License Key for “Windows Server 2008 Std/Ent KMS B”
Note: To License/Activate Server 2008 R2 AND Windows 7 THIS IS THE ONLY KEY YOU NEED. You do NOT need to add additional keys for Windows 7. (You DO for Office 2010, but I’ll cover that below).
2. Armed with your new key, you simply need to change the product key on the server that will be the KMS server, to the new key. Start > Right Click “Computer” > Properties. (Or Control Panel > System). Select “Change Product Key” > Enter the new KMS Key > Next.
3. You will receive a warning that you are using a KMS Key > OK. You may now need to activate your copy of Windows with Microsoft, this is done as normal, if you can’t get it to work over the internet you can choose to do it over the phone.
4. In a corporate environment (behind an edge firewall) you may have the local firewall disabled on the server. If you do NOT then you need to allow access through the local firewall for the “Key Management Service”, (this runs over TCP port 1688). To allow the service, Start > Firewall.cpl {enter} > Allow program or feature through Windows Firewall” > Tick Key Management Service > OK.
Note: Should you wish the change the port the service uses, you can do so with the following command, i.e. to change it to TCP Port 1024;
[box]
cscript c:\Windows\System32\slmgr.vbs /SPrt 1024
[/box]
That’s It! That is all you should need to do, your KMS Server is up and running.
Install Microsoft Windows 2008 R2 Key Management Service from Command Line
You will notice below that I’m running these commands from command windows running as administrator (Right click “Command Prompt” > Run as administrator).
Note: To License/Activate Server 2008 R2 AND Windows 7 THIS IS THE ONLY KEY YOU NEED. You do NOT need to add additional keys for Windows 7. (You DO for Office 2010, but I’ll cover that below).
2. Providing the command runs without error, we have just changed the product key for this Windows server to be the KMS key.
3. Now we need to activate the Windows Server > Run the following command;
[box]
c:\Windows\System32\slui.exe
[/box]
Select “Activate Windows online now” > Follow the on screen prompts.
4. When complete, it should tell you that it was successfully activated.
5. In a corporate environment (behind an edge firewall) you may have the local firewall disabled on the server. If you do NOT then you need to allow access through the local firewall for the “Key Management Service”, (this runs over TCP port 1688). To allow the service, Start > Firewall.cpl {enter} > Allow program or feature through Windows Firewall” > Tick Key Management Service > OK.
Note: Should you wish the change the port the service uses, you can do so with the following command, i.e. to change it to TCP Port 1024;
[box]
cscript c:\Windows\System32\slmgr.vbs /SPrt 1024
[/box]
That’s It! That is all you should need to do, your KMS Server is up and running.
Testing the Key Management Server
Before it will start doing what you want it to, you need to meet certain thresholds, with Windows 7 clients it WONT work till it has had 25 requests from client machines. If you are making the requests from Windows 2008 Servers then the count is 5. (Note: For Office 2010 the count is 5 NOT 25)
Interestingly: On my test network I activated five Windows 7 machines, then one server, and it started working.
Windows 7 and Windows 2008 R2 have KMS Keys BUILT INTO THEM, if you are deploying/imaging machines you should not need to enter a key into them (unless you have entered a MAK key on these machines then you will need to change it to a client KMS Key). These are publicly available (see here).
1. The service works because it puts an SRV record in your DNS, when clients want to activate, they simply look for this record before they try and activate with Microsoft, if they find the record, they activate from your KMS Server instead. If you look on your domain DNS servers, expand “Forward Lookup Zones” > {your domain name} > _tcp > You will see an entry for _VLMCS that points to your KMS Server.
2. From your client machines you can test that they can see the SRV record, by running the following command;
[box]
nslookup -type=srv _vlmcs._tcp
[/box]
Note: If this fails, can your client see the DNS server? And is it in the domain?
3. There is no GUI console for KMS to see its status, so run the following command on the KMS server;
[box]
cscript c:\Windows\System32\slmgr.vbs /dli
[/box]
4. As I’ve mentioned above, with Windows clients you need 25, and Windows Servers you will need 5 requests before KMS will work, before this you will see;
Windows Activation
A problem occurred when Windows tried to activate. Error Code 0xC004F038
5. For each of these failures, look-in the KMS Server, and the “Current count” will increment by 1 till it starts to work). In a live environment this wont be a problem, (You probably wont be looking at KMS with less than 25 clients!). On a test network just clone/deploy a load of machines until you hit the threshold.
Troubleshooting KMS Clients
To make things simple the command to execute on the clients, is the same command that you run on the KMS server to check the status.
[box]
cd c:\windows\system32
slmgr /dli
[/box]
For further troubleshooting, see the following links.
In addition to servers and clients, KMS can activate and handle Office 2010 licenses as well. You simply need to add in Office support, and your Office 2010 KMS key. As mentioned above, unlike Windows clients, you only need five requests to the KMS server before it will start activating Office 2010 normally.
1. First locate your Office 2010 KMS Key! If you have a Microsoft License agreement, log into the the Microsoft Volume License Service Center, and retrieve the KMS License Key for “Office 2010 Suites and Apps KMS”
Note: As with Windows 7, and Server 2008 R2, Office 2010 comes with a KMS key already installed, if you have changed the key to a MAK key you can change it back using the Microsoft public KMS keys (see here).
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
A very long time ago I wrote an article about how to port forward from a public IP address to multiple servers for RDP. Basically you would connect to the firewall using various different ports, and the firewall would change the port to the correct one for RDP (TCP port 3389, unless you changed it on the machine). Then send it to the correct server, so you could manage multiple servers from the same public IP.
Now that was so long ago it was before the version 8.3 NAT changes. This week I was working on a problem where every change I made that had to be tested meant I had to swap VPNs, and reconnect to servers and test comms. This was getting a bit time consuming so I needed a public server to jump on for testing. I didn’t want to expose RDP to my server, so I planned to use a different port and translate that port on the firewall. But how to do that with modern ASA code?
AnyConnect runs over TCP port 443 (That’s HTTPS/SSL), but if you only have one public IP and need to forward that port to a web server or internal host then you are a bit snookered. You can of course change the port that AnyConnect runs over, so that it’s no longer on TCP port 443.
Why you would NOT want to do this.
Bear in mind that https is a well known port, and its open in most places for secure web traffic. You use it when you purchase things over the internet, or do your banking. For that reason it’s allowed from most networks, and through most firewalls. Which is what makes AnyConnect so handy, if you change the port then you may have some connection problems.
Solution
Assuming you accept the potential problems and want to swap the port over then do the following.
3. You can’t change the port while AnyConnect is enabled, so you need to disable it, change the port then re-enable it again (in this example I’ve changed it to port 444).
[box]
PetesASA(config)# webvpn
PetesASA(config-webvpn)# no enable outside
WARNING: Disabling webvpn removes proxy-bypass settings.
Do not overwrite the configuration file if you want to keep existing proxy-bypass commands.
INFO: WebVPN and DTLS are disabled on 'outside'.
PetesASA(config-webvpn)# port 444
PetesASA(config-webvpn)# enable outside
INFO: WebVPN and DTLS are enabled on 'outside'.
PetesASA(config-webvpn)#
[/box]
4. Save the changes with a write mem command.
[box]
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: f3645705 ae6bafda c5606697 ecd61948
9830 bytes copied in 1.550 secs (9830 bytes/sec)
[OK]
PetesASA(config)#
