While attempting to connect to a FortiGate firewall (with Firefox over HTTPS) you may see this error;
Secure Connection Failed
An error occurred during a connection to {x.x.x.x} SSL received a record that exceeded the maximum permissible length error code : SSL_ERROR_RX_RECORD_TOO_LONG
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem
Solution: SSL_ERROR_RX_RECORD_TOO_LONG
My colleague went all round the houses trying to fix this, then asked If I knew what was wrong, annoyingly one Google search gave me the answer;
You can only manage the FortiGate via HTTP when using an evaluation licence!
Related Articles, References, Credits, or External Links
When considering Securing FortiGate remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses). Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?
FortiGate Trusted Hosts
With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.
You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)
System > Administrators > Create New > Administrator.
Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’
Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.
Related Articles, References, Credits, or External Links
When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.
In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication
Solution
The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.
Make Internet Explorer Accept Your Certification Authority
Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.
1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.
2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.
3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.
4. Restart the browser and try again.
Set IIS to serve Certificate Services Securely (via https).
This assumes you have your CA and the web portal installed correctly.
1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.
Note: If https is missing simply add it!
2. Expand Default Web Site > Certsrv > SSL Settings.
3. Tick ‘Require SSL’ > Apply.
4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.
Related Articles, References, Credits, or External Links
FortiGate Remote Access (SSL–VPN ) is a solution that is a lot easier to setup than on other firewall competitors. Here’s how to setup remote access to a FortiGate firewall device, using the FortiClient software, and Active Directory authentication. This is what my topology looks like;
Note: I’ve changed the FortiGates default management HTTPS port from 443 to 4433 (before I started). This was to let me use the proper HTTPS port of 443 for remote access SSL VPN. I suggest you also do this, as running SSL-VPN over an ‘odd’ port may not work from some locations. See the following article;
Certificate: I’m also using a self signed certificate on the FortiGate, in a production environment you may want to purchase a publicly signed one!
Step 1: FortiGate LDAPS Prerequisites
Before we start, we need to make sure your firewall can resolve internal DNS. (Because the Kerberos Certificate name on your Domain Controller(s) gets checked, when doing LDAPS queries, if you DON’T want to do this then disable server identity check when you setup your LDAP server below). Or you can add the IP address to the servers Kerberos certificate as a ‘Subject Alternative Name‘ but thats a bit bobbins IMHO
Network > DNS > Specify > Add in your ‘Internal” DNS servers > Apply.
Certificate Prerequisites
To perform LDAPS the FortiGate needs to trust the certificate(s) that our domain controller(s) use. To enable that you need a copy of the CA Certificate, for the CA that issued them. At this point if you’re confused, you might want to run through the following article;
Click ‘Test Connectivity‘ It should say successful, then you can check some other domain user credentials as a test > OK.
Domain / Active Directory Setup
Over in my Active Directory I’ve created a security group called GS-VPN-Users, and put my user object into it.
Now I need to create a FIREWALL GROUP and add my ACTIVE DIRECTORY GROUP to that. User & Authentication > User Groups > Create New.
Name: Something sensible!
Type: Firewall
Remote Groups > Add.
Change the Remote Server drop down list to be your LDAPS Server > Browse to your ACTIVE DIRECTORY GROUP, right click and Add Selected (Cheers, that took me three goes to find FortiNet!) > OK.
All being well you should see your LDAPS server AND the distinguished name of your AD group, (check that’s not missing!) > OK.
Step 3: Setup FortiGate SSL-VPN
First we need an SSL Portal > VPN > SSL-VPN Portals > Create New.
Name: Something sensible!
Enable Split Tunnelling: Enabled. (If you don’t do this then remote clients need to come though the FortiGate for web access, I usually enable split tunnel).
Source IP Pools: Add Then Create.
Address.
Name: Something sensible!
Type: IP Range
IP Range: The subnet you want to use. (Note:If you are routing on your LAN, make sure there’s a route back to the FortiGate for this subnet or bad things will happen!)
Interface: SSL-VPN tunnel interface
OK.
Enter a portal message, (the header on the page once a remote user connects) > Enable FortiClient download > OK.
If you see the following error, that’s because on some smaller firewalls, (like the 40F) there can only be one, so you need to edit the one that is there by default.
Maximum number 0f entries has been reached.
FortiGate SSL-VPN Settings
VPN > SSL-VPN Settings > Listen on Interfaces.
Set to the outside (WAN) interface > Address Range > Specify custom IP Ranges > IP Ranges > Add in the pool you created above.
DNS Server > Specify > Add in your internal DNS servers > Authentication Portal Mapping > Create New.
Users/Groups: Your AD GROUP.
Portal: Your Portal
OK.
Apply (Note: If it complains ‘All Other User/Group‘ is not configured, set that to web-access (as shown).
From your remote client, browse to the public IP/FQDN of the firewall and log in, you should see the SSL-VPN portal you created, and have the option to download the FortiClient (VPN) software for your OS version.
Install the FortiClient (Note: This is only the VPN component not the full FortiClient).
Remote Access > Configure VPN.
VPN: SSL-VPN.
Connection Name: Something sensible.
Remote Gateway: IP or FQDN of the FortiGate.
Authentication: Prompt on Logon (unless you want it to remember).
Do not warn invalid Server Certificate: Enabled (Unless you are using a publicly signed certificate on your FortiGate).
Save.
Then test connection, make sure you can ping internal IP addresses and DNS names.
Related Articles, References, Credits, or External Links
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
If you have a host that you want to be able to access from the outside of the firewall e.g. a webserver then this is the process you want to carry out. I didn’t find this process particularly intuitive and it highlighted why I don’t like GUI management interfaces, (in 6.4 the menu names have changed, this rendering a million blog pages inaccurate!)
I’m setting this up in EVE-NG on the work bench and this is what I’m trying to achieve;
So to access my web server from ‘outside‘ the firewall I need to give it a NATTED ‘public‘ address on 192.168.100.0/24. Here the server is on the LAN if yours is in a DMZ then substitute the DMZ interface for the inside one I’m using.
Solution
First task is to create a ‘Virtual IP‘, this will be the ‘public IP‘ that the web server will use. From the management interface > Policy and Objects > Virtual IPs > Create New > Virtual IP
‘Give it a sensible name, and add a comment if you wish > Set the interface to the public facing port > Type, set to ‘Static NAT‘ > External IP, (although it says range just type in the single public IP) > Internal IP = Enter the LAN IP > OK.
Firewall Policy > Create New.
Note: If your firewall is older then 6.4 the tab is called ‘IPv4 Policy‘
Give the entry a name > Incoming interface = the public interface > Outgoing Interface = the inside/LAN interface > Source = ALL > Destination = SET TO YOUR VIRTUAL IP > Schedule = Always > Service = ALL (though you can of course select http and or https in production) > DISABLE NAT. (Trust me I know that makes no sense) > OK.
Just to prove this is not all ‘Smoke and Mirrors‘ here’s my topology running in EVE-NG, and my external host (Named: Public-Client) Browsing to 192.168.100.110, and the Fortigate translates that to 192.168.1.123
Related Articles, References, Credits, or External Links
You have a Cisco FTD device that you manage via FDM, and you would like to setup port forwarding. In the example below I will forward TCP Port 80 (HTTP) traffic from the outside interface of my FTD Device (Firepower 1010) to an internal web server on 10.254.254.212
Solution (Step 1: Create an FTD NAT Policy)
Using a web browser connect to the FDM > Polices > NAT > Add.
Set the following options;
Title: Give the NAT rule a title e.g. Webserver-01
Create Rule for: Manual NAT
Status: Enable
Placement: Above a Specific Rule
Rule: InsideOutsideNATRule
Type: Static
Original Packet: Source Interface: inside
Original Packet: Source Address: Select ‘Create New Network’
In the Add new Network Object Window;
Name: Name of the server/object you are port forwarding to e.g. Webserver-01
Host: IP address of the server/object you are port forwarding to
OK
Back At the NAT Rule Window;
Source Address: Ensure it’s set to the object you just created
Original Packet: Source Port: HTTP (or whatever port you wish to forward)
Translated Packet: Destination Interface: outside
Translated PacketSource Address: Interface
Translated Packet: Source Port:HTTP (or whatever port you wish to forward)
OK.
Solution (Step 2: Create an FTD Access Control Policy Rule)
Policies > Access Control > Add.
Set the access rule as follows;
Title: Give the access rule a title e.g. Webserver-Access
Source Zone: outside_zone
Source Networks: any-ipv4
Source Ports: ANY
Destination Zone: inside_zone
DestinationNetworks: The Object you created (above)
Destination: Ports/Protocols: HTTP
OK
You can expand the rule, and see a diagram version if you wish.
Pending Changes > Deploy Now.
Wait! The changes probably haven’t deployed yet, you can check progress by clicking the pending changes button again.
Related Articles, References, Credits, or External Links
Rather by accident I discovered this was not working on the site. I know it used to work, but when the old certificate expired last year I was on holiday in The States, and had a panic trying to disable https, (to keep the site up until I got back and bought a new cert). So I’m guessing its been broken since then.
Solution
I spent about two days looking at forums about how to do this, and every time I edited the NGINX default file, the site stopped working. In the end I found one post in the middle of a discussion about this and that was the ONLY solution that worked for me.
Paste the following WITHIN your server block.
[box]
# Force HTTP to HTTPS Redirection (Entire Site)
if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;
}
[/box]
Related Articles, References, Credits, or External Links
The certificate here at PNL expired over the weekend, I got a new one and installed it. All appeared to be fine until I did an online check to make sure it was OK.
The server’s certificate chain is incomplete
Solution
I had this problem once before, back then I was using Apache and CentOS7, and things were a little different, (now I’m using NGINX and Ubuntu 18.04). Essentially you see this error because you have bought a ‘cheap‘ SSL certificate. There’s nothing wrong with that per se, but they tend to be issued from an ‘Intermediate CA‘. Again there’s nothing wrong with that either, but to improve your score you need to ‘Embed‘ the intermediate certificate, into your SSL certificate, (or all the intermediates back to a Root CA Server, if you have multiple intermediate certificates!)
Here I have ONE intermediate, (which is pretty normal.)
There a no special tools you require to be able to do this, other than a simple text editor, you open your SSL certificate and ‘Paste” the intermediate certificate on the bottom. (DO NOT ADD ANY EXTRA SPACES). Like so;
Note: As you can see, you DON’T put the Root CA certificate at the bottom, (clients should already have them!) I made this mistake then got the following error;
[box]
Jun 23 14:12:29 localhost nginx[1197]: nginx: [emerg] PEM_read_bio_X509("/etc/nginx/ssl/www_petenetlive_com.crt") failed (SSL: error:0906D066:PEM routines:PEM_read_bio:bad end line)
Jun 23 14:12:29 localhost nginx[1197]: nginx: configuration file /etc/nginx/nginx.conf test failed
[/box]
Retry your test.
Related Articles, References, Credits, or External Links
Quite a while ago I wrote the “Connecting to and managing Cisco firewalls” article, which is still pretty complete, but I’ve been asked on a few occasions, “How do I actually configure the firewall to allow remote administration via, SSH, or HTTPS/ASDM, or Telnet
If you have no network connection to the firewall, then you will need to connect via console cable (CLICK HERE).
Solution
Cisco ASA Allow SSH – Via Command Line
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password:*******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine, or a whole network, the syntax is “ssh {ip address} {subnet mask} {interface that you will be connecting to}.
[box]
The following will just allow one external host (123.123.123.123).
PetesASA(config)# ssh 192.168.1.10 255.255.255.255 outsideThe following will just allow a whole internal network 192.168.1.1 to 254
PetesASA(config)# ssh 192.168.1.0 255.255.255.0 inside
[/box]
3. You will need to create a username and password for SSH access, then set SSH to use the LOCAL database to check of usernames and passwords, (unless you are using LDAP, RADIUS, TACACS, or Kerberos for authentication.)
4. By default the SSH session times out after 5 mins, I prefer to change this to 45 minutes.
[box]
PetesASA(config)# ssh timeout 45
[/box]
5. To encrypt the SSH access you need to have an RSA keypair on the firewall, (Note: this is generated from the firewall’s host name, and its domain name, if you ever change either, the keypair will break, and SSH access will cease until the keypair is re-created). To create a key issue a “crypto key generate rsa” command;
[box]
PetesASA(config)# crypto key generate rsa mod 2048
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
PetesASA(config)#
[/box]
Note: I set the key size to 2048, this is considered good practice
7. Lastly, save the changes with a “write mem” command;
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Cisco ASA Allow SSH – Via ASDM (version shown 6.4(7))
1. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select SSH > Supply the IP and subnet > OK. (Note you can set both the timeout, and the SSH versions you will accept, on this page also). Note you still need to generate the RSA Key (See step 5 above, good luck finding that in the ASDM – see the following article).
Cisco ASA – Enable AAA for SSH (Local Database) ASDM version 6.4(7)
Cisco ASA – Add a User to the Local Database
Cisco ASA – Allow HTTPS/ASDM – Via Command Line
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password: *******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine or a whole network, the syntax is “http {ip address} {subnet mask} {interface that it’s connected to}.
[box]
The following will just allow one host (192.168.1.10).
PetesASA(config)# http 192.168.1.10 255.255.255.255 inside
The following will just allow a whole network 192.168.1.1 to 254
PetesASA(config)# http 192.168.1.0 255.255.255.0 inside
[/box]
3. Unlike telnet and SSH, HTTPS/ADSM access is via the firewalls enable password (Unless you have enabled AAA logon). this password is set with the “enable password {password}” command. (Note: You will already have entered this password in step 1, only do this if you wish to change it).
[box]
PetesASA(config)# enable password PASSWORD123
[/box]
4. You need to make sure that HTTPS access is enabled with a “http server enable” command.
[box]
PetesASA(config)# http server enable
Note: if your port forwarding https on your firewall you will NOT be able to get access externally unless you put it on a different port (i.e.1234).
PetesASA(config)# http server enable 1234
[/box]
5. Lastly, save the changes with a “write mem” command.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
OK, the title of this might raise an eyebrow, but if you have access to the ASDM and you want to grant access to another IP/Network them you might want to do this. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select ASDM/HTTPS > Supply the IP and subnet > OK. (Note: You can also enable and disable the http Server here and change its port number).
Cisco ASA Allow Telnet – Via Command Line
WARNING: Telenet is insecure, if possible don’t use it, (usernames and password are sent unencrypted.)
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password: *******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine, or a whole network, the syntax is “telnet {ip address} {subnet mask} {interface that its connected to}.
[box]
The following will just allow one host (192.168.1.10).
PetesASA(config)# telnet 192.168.1.10 255.255.255.255 insideThe following will just allow a whole network 192.168.1.1 to 254
PetesASA(config)# telnet 192.168.1.0 255.255.255.0 inside
[/box]
3. To set the password you use the “passwd” command (yes that’s spelled correctly).
[box]
PetesASA(config)# passwd PASSWORD123
[/box]
4. By default the telnet session times out after 5 mins, I prefer to change this to 45 minutes.
[box]
PetesASA(config)# telnet timeout 45
[/box]
5. Lastly, save the changes with a “write mem” command.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Allow Telnet – Via ASDM (version shown 6.4(7))
1. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select Telnet > Supply the IP and subnet > OK. (Note you can set the timeout on this page also).
Related Articles, References, Credits, or External Links
