Directly on an ESX Host: If you have a stand-alone ESX Server running version 8.x, Log in via the web console > Select ‘Host’ > Actions > Services > Enable Secure Shell (SSH).
Via vSphere/vCenter: If you want to enable SSH on an ESX host through the vCenter Web client then, from the ‘hosts and datacentres’ view > Select the Host > Configure > Services > Locate SSH > Start.
Enable SSH Permanently: Some people don’t want this enabled for security reasons, and in production that makes sense, but on my test network I always have SSH enabled. from the same screen as above with SSH selected > Edit Start-up Policy > Select ‘Start an stop with host” > OK.
VMware Enable SSH 6.5
If you have a stand-alone ESX Server running version 6.5, it’s a lot easier to enable ESX access. Select ‘Host’ > Actions > Service > Enable Secure Shell (SSH). Note: You can also enable the direct console access here.
If you want to enable SSH on an ESX host through the vCenter Web client then, from the ‘hosts and datacenters’ view > Select the Host > Configure > Security Profile > Scroll down to ‘Services’ > Edit.
Locate ‘SSH > Start > OK.
Once enabled you will see the following warning on the hosts summary page, however, in version 6.5 you can suppress this error.
VMware Enable SSH ESX 5
ESX 5 has a built in firewall, which can have SSH opened in the VI clients, or just as with version 4.1.0 you can enable SSH Locally from the console from troubleshooting options.
Enable Remotely
1. Log into the host with the VI client > Select the host > Configuration > Security Profile > Properties.
2. Locate SSH Server > Tick it > Options > You can either manually start it or set it to start automatically.
3. You will see the following warning to “retrieve” the firewall settings (because you have just changed them) > Select Yes.
Note: Having it running will still cause the “Configuration Issues – SSH for the host has been enabled” nag screen on the summary tab of the host.
VMware Enable SSH ESX 4.0.1
Starting with version 4.0.1 you can enable SSH access from the server console.
1. Go to the normal ESX console > Press F2 > Log in >Troubleshooting Options.
2. Select “Enable Remote Tech support” toggle on and off with {enter} if you want to SSH in the server remotely using PuTTy for example > If you want to log on directly at the console choose “Enable Local Tech Support”.
3. Note: Having it running will still cause the “Configuration Issues – Remote Tech support Mode (SSH) for the host {hostname} has been enabled” nag screen on the summary tab of the host.
Grant SSH Access to ESX 4.0.0 and earlier
1. Go to the normal ESXi console.
2. Press ALT+F1 > the screen will change > Type unsupported {enter} > Note: Nothing will appear on the screen till you hit {enter} > Type in the root password and press {enter}.
3. You now need to edit a config file, the only editor we have is vi (sorry) issue the following command,
[box]vi /etc/inetd.conf[/box]
4. The vi editor will open the file, use the arrow keys to move down to the line that says,
[box]#ssh stream tcp nowait root…[/box]
Press I on the keyboard (that puts the vi editor into insert mode) and delete the hash “#” mark from the beginning of the line.
5 Then, to save the changes press {Esc} > type in :wq {Enter} (that’s write the changes and quit if you’re interested).
6. Enter the following command.
[box]
cat /var/run/inetd.pid
[/box]
It will provide you with a number, (in the example below its 4983, yours will be different).
7. Issue the following command.
[box]
kill -HUP {the number you got from above}
[/box]
8. To get back to the usual ESXi screen and exit command line press ALT+F2.
9. You can now connect with an SSH client like Putty.
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
Unless your firewall is brand new (in which case the passwords will either be {blank} or cisco), to access a Cisco firewall you will need a password, (this stands to reason it is a security device after all!).
Cisco Firewall Usernames
As for usernames, with a few exceptions, you do not USUALLY need a username. Those exceptions being;
Access via SSH needs a username (before version 8.4 you could use the username pix, and the Telnet password, this no longer works).
If you have set up authentication to be done by AAA.
Cisco Firewall Forgotten Password Recovery
If you do not know the password then you need to perform some password recovery.
Cisco ASA – Methods of Access.
1. Console Cable: This uses the rollover cable that came with the firewall, They are usually pale blue in colour, and the more modern ones have a moulded serial socket on them. The older ones have a grey network to serial converter that plugs on the end. Access is via some Terminal Emulation Software, e.g. PuTTy or HyperTerminal. This method of access is enabled by default, but requires physical access to the devices console port.
2. Telnet: This simply allows connection via a telnet client, all versions of Windows have one, though Microsoft have done a good job of Hiding it in Windows 7. You can also use PuTTy, HyperTerminal, or another third party telnet client. This is considered the LEAST SECURE method of connection, (as passwords are sent in clear text). On a new firewall the telnet password is usually set to cisco (all lower case).
3. Web Browser: (How the vast majority of people access the firewall). Depending on the age and version of the firewall dictates what “Web Server” you are connecting to, devices running Version 7 and above use the “Adaptive Security Device Manager”. Cisco firewalls running an Operating system of version 6 and below use the “PIX Device Manager”. Both the ADSM and the PDM have a similar look and feel, and both require you have to Java installed and working.
4. SSH: Secure Sockets Handshake: This is sometimes called “secure telnet” as it does not send passwords and user names in clear text. It requires you supply a username and a password. Firewalls running an OS older than 8.4 can use the username of pix and the telnet password. After version 8.4 you need to enable AAA authentication and have a username and password setup for SSH access.
5. ASDM Client software: (Version 7 firewalls and above). You will need to have the software installed on your PC for this to work (you can download it from the firewall’s web interface, or install from the CD that came with the firewall).
Cisco ASA Remote Management via VPN
Even if you allow traffic for a remote subnet, there are additional steps you need to take to allow either a remote client VPN session, or a machine at another site that’s connected via VPN. Click here for details.
Solution
Connecting to a Cisco Firewall Using a Console Cable
Obviously before you start you will need a console cable, you CAN NOT use a normal network cable, OR a crossover cable as they are wired differently! They are wired the opposite way round at each end, for this reason some people (and some documentation) refer to them as rollover cables. They are usually Pale blue (or black). Note if you find your console cable is too short you can extend it with a normal network cable coupler and a standard straight through network cable.
On each end of the console cable the wiring is reversed.
Old (Top) and New (Bottom) versions of the Console Cable.
Note: If you don’t have a serial socket on your PC or Laptop you will need a USB to Serial converter (this will need a driver installing to add another COM Port to the PC).
Option 1 Using PuTTY for Serial Access.
1. Connect your console cable, then download and run PuTTy. (I’m assuming you are using the COM1 socket on your machine, if you have multiple serial sockets then change accordingly).
2. By default PuTTy will connect with the correct port settings, if you want to change the settings see the option I’ve indicated below. Simply select Serial and then ‘Open’.
3. You will be connected. (Note: The password you see me entering below is the enable password).
Option 2 Using HyperTerminal for Serial Access
1. Connect your console cable, then download install and run HyperTerminal. (Note: With Windows XP and older it’s included with Windows, look in > All Programs > Communications). Give your connection a name > OK.
2. Change the ‘Connect Using’ option to COM1 > OK.
3. Set the connection port settings from top to bottom, they are, 9600, 8, None, 1, None > Apply > OK.
4. You will be connected. (Note: The password you see me entering below is the enable password).
Connecting to a Cisco Firewall via Telnet
To connect via telnet, the IP address you are connecting from (or the network you are in) has to have been granted access. If you cannot access the firewall using Telnet then you will need to connect via a console cable. Note Windows 7/2008/Vista needs to have telnet added.
Option 1 Use Windows Telnet Client for Firewall Access
1. Ensure you have a network connection to the firewall and you know its IP address > Start.
2. In the search/run box type cmd {enter}.
3. Execute the telnet command followed by the IP address of the firewall.
Also to access via this method you need to know the firewall’s “Enable Password”. If you use a proxy server then you will need to remove it from the browser settings while you carry out the following. Ensure also that you have Java installed and working.
1. Ensure you have a network connection to the firewall and you know its IP address > launch your web browser.
2. If you are using IE7 (or newer) you will need to click “Continue to this web site (not Recommended)”. IE6 Users will see this instead.
3. Click “Run ASDM” (older versions say ‘Run ADSM Applet’). Note: for information on the other option ‘Install ASDM launcher…’ see connecting via ASDM).
The Startup Wizard is for setting up a new firewall, I don’t recommend you ever use this unless you follow this guide.
4. You might receive a few Java warning messages, answer them in the affirmative.
Note: After version 8.4 you can only access the Cisco ASA using AAA authentication, see here. Prior to version 8.4 you can use the username of ‘pix’ and the firewall’s telnet password.
1. Ensure you have a network connection to the firewall and you know its IP address > Launch PuTTy.
2. Tick SSH > enter the IP address of the firewall > Open.
3. The first time you connect you will be asked to accept the certificate > Yes.
4. You will be connected, supply the username and password configured for AAA access., (or username pix and the telnet password if you are older than version 8.4).
Connecting to a Cisco Firewall via ASDM Client Software
1. Ensure you have a network connection to the firewall and you know its IP address > launch your web browser.
2. If you are using IE7 (or newer) you will need to click “Continue to this web site (not Recommended)”. IE6 Users will see this instead.
3. Select ‘Install ASDM Launcher and Run ASDM’.
4. The username is usually blank (unless you are using AAA), and you will need to enter the enable password.
5. Run (or save if you want to install manually later).
6. Accept all the defaults.
7. The ASDM, will once again ask for the password. (By default it will place a shortcut on the desktop for the next time you need to access the firewall).
8. The ASDM will launch and you will be connected.
Connecting to a Cisco Firewall via Pix Device Manager
1. Open your web browser and navigate to the following,
https://{inside IP address of the firewall}
Note if you are using IE7 (or newer) you will need to click “Continue to this web site (not Recommended)”.
IE6 Users will see this instead
2. If Prompted leave the username blank, and the password is the firewall’s enable password.
Note if you are using AAA you might need to enter a username and password.
3. You will see this.
4.You might receive a few Java warning messages, answer them in the affirmative, on some newer versions of Java you may also need to enter the password a second time.
5. The PDM opens. You are successfully connected.
Related Articles, References, Credits, or External Links
I wanted to perform command line access to a virtual firewall on my home ESXi server, (a Juniper Firefly vSRX) via a console session. To do that I needed to add a serial port to that VM.
Solution
1. From Within the VI client > Select the ESXi Host > Configuration > Security Profile > Firewall Section > Properties.
2. Locate and enable ‘VM serial port connected over network’ > OK.
3. From the actual VM‘s properties, (right click > Edit settings) > Add > Serial Port > Next.
4. Connect via Network > Next.
5. Select ‘Server (VM listens for connection)’ > In Port URI enter telnet://{IP-of the ESX-Server}:2001 > Next.
Note: That’s the IP of the ESX server NOT the VM, here I’m using port 2001, but you can use 23 (standard telnet), or a random port above 1024.
6. Review the settings > Finish.
7. Now on a machine that has network connectivity to the ESX server > launch a telnet session to the VM (remember to use port 2001 as telnet defaults to 23!).
Here I’m using PuTTY but you can run ‘telnet {ip-address} {port}’ from a Windows client, (providing you have telnet enabled).
8. I’m in and working.
Related Articles, References, Credits, or External Links
This procedure was carried out on a Draytek Vigor 2800 Router, for this I needed to forward RDP (That’s on TCP Port 3389).
Warning: If you need to forward any of the following ports 23 (Telnet), 80 (HTTP) , 443 HTTPS/SSL), 21 (FTP), or 22 (SSH). The Draytek has these reserved for remote management. You will need to change the port number (system Maintenance > Management > Management Port Setup).
Solution
1. Log into the routers web console (default will be a blank username and password, or admin and admin, or admin and blank password).
2. Give the service a name (Like RDP) > Enter the protocol type TCP or UDP > Enter the internal IP that you want to forward the port to > Tick active > Click OK.
Note: Depending on setup you may see this instead (if that’s the case select the correct public IP)
3. That should be all you need to do, unless the firewall is turned on, if that’s the case expand NAT > Open Ports.
4. Again enter a name in the comment box > The local IP of the machine > and the port details > OK.
Related Articles, References, Credits, or External Links
Telnet client from Windows, and have it as an “Optional Extra”. For most people that’s fine, but for anyone who programs network devices, or needs to test that ports are open, or test mail flow by telnet to port 25, that’s a pain.
This one had me well and truly stumped! The client has two sites and from their remote site they could not open a remote Desktop connection to a server at the main site.
RDP Stuck at Securing remote connection.
At first, because the client had SBS at their main site I assumed this was the problem, but sadly it was not.
Solution
The following process goes through the steps taken to identify and rectify the problem.
1. Firstly, I’m assuming you can ‘ping’ the target server both by name and IP address, if you can’t do this, then read no further, you have a communication problem, fix that first!
2. Check that RDP (TCP Port 3389) is open by attempting to Telnet to that port on the destination server.
If you simply see a ‘cursor’ then the port is open, if not it will give you an error. (If that is the case then you need to look at comms to make sure TCP Port 3389 is not being blocked, either by a hardware firewall/router, or a software firewall on either of the machines.)
3. Check no third party security software is blocking RDP, by issuing the following command;
[box]
fltmc[/box]
This indicates the machine I’m on is running, “Trend Micro’.
4. Try disabling the security software to see if that rectifies the problem,
After much hand wringing, and a few days of rebuilding firewall VPNs, patching servers, and installing hot-fixes, I admitted defeat and got Microsoft on the phone.
5. The fist thing they found, was if they attempted to open a UNC path to the destinations server IP address it worked.
6. BUT If they did the same to the server name it failed.
Error:The specified network name is no longer valid
7. Normally this is an indication that the secure channel between this machine, and the target machine is broken. Normally this can be fixed with the following commands;
[box]
net stop KDC
klist purge
netdom resetpwd /server:{IP address of domain controller}/userd:{your-domain-name}administrator /passwordd:*
Then supply the domain administrators password
net start KDC
[/box]
However this did not fix our problem, but indicated that it was not just RDP that was failing. Both the machine we were using, and the destination machine were domain controllers, so domain replication was checked and the following was found;
Event ID 1865
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1311
Task Category: Knowledge Consistency Checker
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
The Knowledge Consistency Checker (KCC) has detected problems with the following
directory partition.
Directory partition: CN=Configuration,DC=your-domain,DC=com There is insufficient site connectivity information for the KCC to create a spanning tree replication topology. Or, one or more directory servers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible directory servers. User Action Perform one of the following actions: – Publish sufficient site connectivity information so that the KCC can determine a route by which this directory partition can reach this site. This is the preferred option. – Add a Connection object to a directory service that contains the directory partition in this site from a directory service that contains the same directory partition in another site.
Event ID 1311
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1566
Task Category: Knowledge Consistency Checker
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
All directory servers in the following site that can replicate the directory partition
over this transport are currently unavailable.
Event ID 1566
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1865
Task Category: Knowledge Consistency Checker
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology. As a result, the following list of sites cannot be reached from the local site.
Sites:
CN=Your-OU,CN=Sites,CN=Configuration,DC=your-domain,DC=com
8. So we DO have a communications problem, some things work others do not! Let’s make sure our traffic is not getting fragmented, you would expect a packet of 1500 bytes to be able to get though, ours did not, using trial and error Microsoft ascertained that 1320 was the highest we could get though without error.
[box]
ping -f -l {packet size}
[/box]
Note: To get the figure exactly right, you need to keep decreasing the packet size by 1, then when you have found the largest size permissible, you need to add 28 to it (for the overhead of the IP Header).
9. So the MTU was ‘locked’ at BOTH ENDS (source machine and destination server). To do so, Windows Key+R > regedit > Navigate to;
Note: There may be many ‘keys’ here, check each one in turn, to find the one that equates to the IP address on your machine, (the one you are working on).
When you have located the correct key, create a new DWORD (32 bit) value (or edit one if it exists) set the DECIMAL value to the same size that you could get though without error in step 8.
10. Reboot the machines and try again.
Related Articles, References, Credits, or External Links
Special thanks and credit to Harprit Singh at Microsoft, for his hard work and outstanding support.
Usually when you Telnet to an Exchange server it gives you a 220 message followed by the “Banner” of the Exchange server, a little like:
220 Servername.domainname.com Microsoft ESMTP Mail service ready at (Date/Time)
The reason why you see this happening is, there is something in between you and the Exchange server that’s stopping/filtering ESMTP traffic.
In this clients case I knew straight away what that was, (because I’d seen it before,) Cisco firewalls (PIX and ASA) that have SMTP/ESMTP inspection enabled cause this to happen.
Disable ESMTP Inspection on Cisco ASA Via command line
Note: If you send mail via TLSDO NOT do this. (see here).
2. Usually you will find ESMTP inspection enabled on the “global_policy” in the class called “inspection_default”, below are the commands to disable this feature.
When Email was a new medium, pretty much all mail servers were open relays, and nobody really cared, after all if someone in Nigeria wanted to relay mail through a college server in Manchester then why shouldn’t they? Sadly with the explosion of Email and internet use this is no longer an option, because all those annoying Emails you get for Viagra or insider stock tips have probably been sent to you through an open relay. That’s to say someone like you with a mail server that’s happily sending out someone else’s mail.
Now you may be the sort of person who does not care, if that’s true then “be warned” Major ISP’s and Email handlers are routinely blocking “Suspect” mail servers, you might not even know you had a problem, and the first thing you know about it is,you cant send mail to a particular domain because you are on a blacklist, or worse your ISP cuts off your internet access, or you get an early knock on the door from some nice men in suits wanting to know why 400Gb of “dodgy photos” was sent from your IP address this morning.
Solution
Test your Mail Server with Telnet
1. OK – the first thing we need to do is get on a PC that isn’t logged into the domain (Exchange can be set to relay mail from a client that’s authenticated to the domain regardless) – So take that out of the equation by not being in the domain. Now open a good old fashioned command window . Click Start > Run > CMD {enter} Alert! – To put “Run” on your start menu > Right click your task bar > Properties > Start Menu Tab > Customise > Tick “Run Command” > OK > OK.
2. You now need to connect to your mail server using a telnet command, to do this you need to know either the name or the IP address of the server. the command is,
telnet <IP Address or Server Name> 25 {enter}
3. The server should respond with a “Banner” this lets you know you connects successfully NOTE some anti virus programs block this (McAfee for example) you need to go to its access protection settings and untick “Prevent mass mailing worms from sending mail”. Don’t forget to turn it back on again later 🙂
4. You are going to send an Email from command line, the first thing you need to do is say hello to the server, though being an exchange server the command is,
ehlo {enter}
What we want to see are 250 messages in our example we got,
250-server1.petenetlive.com Hello [10.254.254.60]
5. Type the following,
mail from:test@test.com{enter}
again we want to be seeing a 250 message, if you didn’t get one you made a spelling mistake start again 🙁
In our example we got,
250 2.1.0 test@test.com….Sender OK
6. Now we are going to attempt to relay mail for a different domain this will tell us if the server is an open relay or not. Type the following,
rcpt to:badperson@nastyspammer.com{enter}
Note if the Server gives you a message like,
550 5.7.1 Unable to relay for badperson@nastyspammer.com THIS MEANS YOU ARE NOT AN OPEN RELAY.
NOTE if the server responds with
250 2.1.5 badperson@nastyspammer.com
Then either you ignored me in step 1 and your in the domain – or YOU ARE AN OPEN RELAY.
Officially there are three things, that if set wrong can leave you as an open relay,
1. Your Default SMTP Virtual Server.
2. Your SMTP Connector.
3. You have ISA server installed and set incorrectly.
Step 1 – Check the SMTP Virtual Server
1. On the Exchange Server Click Start > All Programs > Microsoft Exchange > System Manager.
2. Expand Administrative Groups > First Administrative group > Servers > {your server name} > Protocols > SMTP > Right Click “Default SMTP Virtual Server” > Properties.
3. On the properties window select the Access tab > Click the “Relay” Button.
4. On the “Relay Restrictions” window Check that, “Only the list below” is selected > It’s not unusual (in fact its the default) that the window is empty, you may see the Exchange server IP addresses in here – or in some cases other hosts on your network that have been set up to relay mail – (Backup software that emails you, or SQL servers that email events for example) > And ensure the box at the bottom that says “Allow all computers that successfully authenticate to relay, regardless of the list above” IS TICKED.
Step 2 – Check the SMTP Connector
NOTE: You might not have an Exchange connector don’t panic if its not there 🙂
1. On the exchange Server Click Start > All Programs > Microsoft Exchange > System Manager.
2. Expand Administrative Groups > First Administrative group > Routing Groups > First Routing Group > Connectors. > {your connector name} NOTE – you may have many different routing groups and the path in your exchange system manger might be under Servers > {your server name} > Connectors.
3. Right click your connector and select Properties.
4 Select the “Address Space” Tab > You should see the following > Address Type = SMTP > Address = * > Cost = 1 > Connector Scope = “Entire Organisation” > “Allow Messages to be relayed to these domains” IS NOT TICKED.
Step 3 – Check ISA
ISA Server 2000 – had a problem where if you had a mail publishing rule for SMTP it set an open relay -check! Also make sure make sure 127.0.0.1 is NOT in the list of IP addresses that are allowed to relay in the the properties section of the default SMTP Virtual server.
Related Articles, References, Credits, or External Links
While putting in a New Exchange 2010 server today, I test moved a mailbox to this new site, and could not get mail to flow to the Exchange 2010 server at the clients main site.
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
Mail flowed from the main site to this new site, and internal mail at the new site was fine, but any mail destined for the main site, or going external (because the main site has the only server that can use the Exchange organization send connector) would fail with this error.
Solution
I did a lot of trawling to try and find the answer to this, and discovered lots of reasons for this to happen, so rather than just posting what fixed mine, from the most popular to the most obscure try these in order, and attempt to send mail after each step.
Note: Any change on an Exchange Server’s Receive Connectors should be followed by you restarting the Microsoft Exchange Transport Service (on the server you made the change on) before you try again.
1. On the server you are trying to send TO, check the properties of the Default receive connector and ensure ‘Exchange Server authentication’ is selected.
2. On the server you are trying to send TO, If you have a connector configured to ‘relay’ mail, make sure that the server(s) or network specified DOES NOT include the IP address of the server you cannot send FROM. Also Make sure on the authentication tab ‘Exchange Server authentication’ is NOT selected.
3. If you have Cisco PIX Firewalls between these two mail servers (running version 6 or earlier) make sure smtp fixup is disabled.
[box]
Petes-PIX>
Petes-PIX> enable
Password: *******
Petes-PIX# configure terminal
Petes-PIX(config)# no fixup protocol smtp 25
Petes-PIX(config)# write mem
Building configuration...
Cryptochecksum: f59a9bd3 3129b8bc 474b2415 52f2db0f
1049 bytes copied in 0.430 secs
[OK]
[/box]
4. If you have Cisco ASA Firewalls between these two mail servers, then remove esmtp from the default inspection map.
At this point I admitted defeat and picked up the phone and called Microsoft. One of their support engineers looked at the connectors and settings, and tested the DNS, had me create a new connector, still mail refused to flow. He did however get me pointed in the right direction. When attempting to Telnet to the Exchange server on the main site this is what we saw;
This is what we should be seeing;
Eureka!
I put all the firewalls in, so I know how they are configured, and I know this client has a CSC module in the ASA 5510 at the mail site, I managed to get the output above by rebooting that module, as soon as it was back online we reverted to the short list again. Also while the CSC was rebooting all the mails stuck on the outbound queue cleared.
Enabling CSC Bypass for a Remote Mail Server
Note: Your class-maps, and access-lists may have different names but this should point you in the right direction.
1. Connect to the ASA, view the policy-maps in use.
[box]
Petes-ASA# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect pptp
inspect ip-options
class global-class <<<<< Here we go
csc fail-open <<<< This is the one we are looking for
!
Petes-ASA#
[/box]
2. We can see the class-map the CSC is using is called ‘global-class’, let’s take look at that.
[box]
Petes-ASA# show run class-map global-class
!
class-map global-class
match access-list global_mpc <<<<Here's how its being applied
!
[/box]
3. Now we know that’s being applied with an access-list called global_mpc, let’s see what that’s doing.
[box]
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
Note: Remember permit means inspect and deny means don’t inspect, you can see mine’s set not to scan the CSC update traffic because that’s good practice;
4. So I just need to add in the IP of the Exchange server I cannot send from to make its traffic bypass the CSC Module. Remember to put it at the top so it gets processed before the permit or it will get ignored.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 extended deny ip host 10.3.0.2 any
