Certified working all the way up to macOS Ventura version 13.6
Certified working all the way up to macOS Sonoma version 14.1
I thought my RoyalTSX had broken today, I upgraded it a couple of weeks ago, and I upgraded to macOS Catalina 10.15 the other day. After this, all my SSH sessions refused to connect with this error;
Unable to negotiate with x.x.x.x port 22: no matching key exchange found. Their offer diffie-hellman-group1-sha1
Note: You may also see the following error;
Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
Update: 10/04/20: With newer equipment you may see the following error;
Unable to negotiate with x.x.x.x port 22: no matching MAC found Their offer: hmac-sha2-256
Update 08/12/21: With newer Cisco equipment you may see the following error;
Unable to negotiate with x.x.x.x.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Mac SSH Error – Fix
WARNING: My usual fix for this is to edit the macs ssh_configfile directly and allow the older (less secure) connection methods. It has been (correctly) pointed out, that this is the ‘least preferred‘ method, as it will allow these less sure methods for ALL SSH connections. The preferred fix, is to create a new file in your own home folder, with the connection settings for EACH SSH CONNECTION. However, I manage hundreds of firewalls. routers and switches so that method is a little unwieldy for me. But I will include it at the end of the article, for the more security conscious of you.
Not Apple’s fault to be fair, it’s OpenSSH version 7. SHA1 is weak, so support for it has been removed. Which is fine, but all my clients Cisco Firewalls, Routers, Switches are probably all using RSA/SHA1. So until they re all updated I’m going to need to re-enable SHA1.
Open a terminal windows and execute the following;
[box]
sudo nano /etc/ssh/ssh_config
ENTER YOUR PASSWORD
[/box]
Locate the line ‘ # MACs hmac-md5,hmac-sha1,hmac-sha2-256,umac-64@openssh.com,hmac-ripemd160′ and remove the Hash/Pound sight from the beginning, and add the extra hashing algorithm that I’ve shown above in red.
Locate the line ‘ # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc’ and remove the Hash/Pound sight from the beginning.
To quit nano, use the Ctrl-X key combination. because you are working on has been modified since the last time you saved it, you will be prompted to save the file first. Type y to save the file.
Theres no reason to reboot, it should work straight away.
But Wait – Theres More!
It’s going to happen every time you upgrade your mac, I’ve started taking a backup of the ssh_config file, then I can just restore it back again, like so;
Using this method you will create a connection (entry) for each asset you want to connect to. This will be saved in your Home directory so if multiple people use the Mac you will need to do this for each user.
Firstly create a config file in you home directory.
[box]
sudo nano ~/ssh/config
[/box]
What this does is create a blank file that you can then create an entry for each of the assets you want to connect to. Firstly specify the hostname, then the settings for that particular asset, like so:
[box]
Host YOUR-SWITCH
User YOUR-USER
port 22
KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
PubkeyAcceptedAlgorithms +ssh-rsa
HostkeyAlgorithms +ssh-rsa
[/box]
Note: Simply add new host entries at a new line in the SAME config file.
Related Articles, References, Credits, or External Links
The one reason I prefer Cisco over Microsoft is they rarely change things, you learn how to do something and it’s learned. This is the second time have had to write this article purely because the Azure UI has changed!
Virtual Network Gateway Options
With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Policy Based, for the more modern Route based option, see the following link;
These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).” Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, In Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”.
Advantages:
Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
Can be used with Cisco ASA OS (pre 8.4) IKEv1 only,
Disadvantages
Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.
Route Based
These were typically used with routers, because routers use Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). But Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1))
Advantages
Can be used for VPNs to multiple sites.
Disadvantages
Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.
Configure Azure for ‘Policy Based’ IPSec Site to Site VPN
You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.
Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.
OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name‘and ‘address range‘ that things will actually connect to, (10.0.0.0/24).
All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.
To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created.
With your virtual network selected >Subnets > +Gateway Subnet.
You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) > put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.
All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Policy Based (Note: This will change the SKU to Basic) > Create New Public IP > Give it a Name > Create.
Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.
You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!
Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.
Configure the Cisco ASA for ‘Policy Based’ Azure VPN
I read somewhere that the ASA had to be at 9.1? That’s not true, I’ve done it with a firewall running 8.3, and I’ve read blog posts from people who have done this with a Cisco PIX (running version 6). But the firewall does have to support AES encryption (‘show version’ will tell you). There are some subtle differences in the code which I will point out below, but essentially you should be running an OS newer than 8.4 for this config to work. (As I’ve said I’ll address 8.4, and 8.3 (or earlier) below).
Connect to the ASA and create an object group for your local subnet, and the subnet that you are using in Azure, (Called Azure-SN above).
[box]
Type help or '?' for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)# object-group network OBJ-AZURE-SN
Petes-ASA(config-network-object-group)# description Azure Subnet
Petes-ASA(config-network-object-group)# network-object 10.0.0.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
Petes-ASA(config)# object-group network OBJ-LOCAL-SN
Petes-ASA(config-network-object-group)# description Local Subnet
Petes-ASA(config-network-object-group)# network-object 192.168.100.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
[/box]
Then create an access-list, this will alert the firewall that there is some ‘interesting traffic’ that needs to be encrypted (we will call this ACL later on, from the crypto-map). Then create a NAT rule that stops traffic that’s going over the VPN tunnel from being NATTED.
Our VPN is going to use a pre-shared-key, (you created in Azure above). It will use AES-256 for encryption, SHA for hashing, and Diffie Hellman version 2 for key exchange. So we need to have a matching ‘phase 1’ (that’s ISAKMP) policy.
Enable ISAKMP (version 1) on the outside interface, then configure the parameters that will be used in ‘phase 2’ (that’s IPSEC). Note: If your outside interface is called something else like Outside or WAN substitute that!
Next, you need a tunnel-group, in this case the only job of the tunnel group has is to keep the pre-shared-key (PSK) to the peer you specify. Which in this case is the Azure Gateway.
The thing that ties it all together is the crypto map. Here I’ve called it “AZURE-CRYPTO-MAP”, WARNING if you already have a crypto map, use the name of that one, or all your existing VPNS will stop working, (show run crypto will tell you). This is because, you can only have one crypto map applied to an interface, but you can have many crypto map numbers, i.e crypto map {NAME} {NUMBER} {COMMAND}. And each VPN tunnel has its own number.
There are a couple of extra commands you will need, these are sysops commands. Their purpose set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.
To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging 8.8.8.8 that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.
As mentioned above, you might want to turn the firewalls off to test.
On the Cisco ASA you can see the tunnel is established at Phase 1 (ISAKMP)
[box]
Petes-ASA# show cry isa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 40.113.16.195
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
[/box]
If yours says something else, (or nothing at all) then phase 1 has not established. You need to Troubleshoot phase 1 of the VPN tunnel. (Probably: Public IP is wrong, or pre-shared-key (shared secret) has been mistyped, check these first).
Assuming that’s working, your next test is to make sure that Phase 2 has established. You should see packets encrypting and decrypting.
[box]
Petes-ASA(config)# show cry ipsec sa
interface: outside
Crypto map tag: AZURE-CRYPTO-MAP, seq num: 1, local addr: 128.65.98.43
access-list ACL-AZURE-VPN extended permit ip 192.168.100.0 255.255.255.0 10.0.0.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer: 40.113.16.195
#pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 128.65.98.43/0, remote crypto endpt.: 40.113.16.195/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 97624DA8
current inbound spi : D7705547
inbound esp sas:
spi: 0xD7705547 (3614463303)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000000F
outbound esp sas:
spi: 0x97624DA8 (2539802024)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box] If phase 2 did not connect, then you need to troubleshoot phase 2 of the VPN tunnel. (Probably: Transform set is wrong, or routing being the ASA is not working).
Azure to Cisco VPN ‘Policy Based’ IKEv1 Complete Code Snippets to Copy and Paste
(Change the values highlighted in red)WARNING: re-read the warning about crypto map names above! [box]
You want to wipe the firewall’s config and revert to the factory settings (passwords blank – management or inside set to 192.168.1.1 and DHCP enabled, with all other settings wiped).
Solution
1. Connect to the ASA via the console Cable. CLICK HERE
2. log in and go to configure terminal mode.
3. Execute the following command “config factory-default”
4. Press the space bar a few times to execute the commands.
5. When you get back to command prompt Execute the following command “reload save-config noconfirm” (Or on a Cisco PIX, write mem {enter} > reload {enter}{enter}).
6. The Firewall will reboot, (set to factory settings).
Procedure carried out on a Cisco ASA 5508-X (Running version 9)
Procedure carried out on a Cisco PIX 515E (Running version 8)
Note: Now the management interface, (if you have one) will be set to lease DHCP addresses. If you don’t have a management interface, (i.e. you have an ASA 5505, or an older PIX,) then the inside interface will lease DHP addresses instead. The outside interface will be set to obtain its IP address via DHCP.
Related Articles, References, Credits, or External Links
I have a client who had two sites, one didn’t have a particularly good internet connection, (which is the actual problem that needed to be solved). But in the interim, he wanted me to prioritise RDP traffic, as his staff were constantly complaining about the speed of their connections.
Note: They may be a myriad of reasons why user experience is bad for an RDP session, this was quite simply a bandwidth issue.
The client requested I prioritise RDP traffic on the link. We were not really sure if that would cure the problem, but they have not complained since!
Solution
On the main site, (with the RDP server(s) on), create an ‘access-list‘ to match our interesting traffic. (I’m just using ‘any’ as the source.)
Here we are dealing with the older IPSEC VPN method of remote VPNs, NOT AnyConnect. There is/was a VPN client for Mac OSX which you can still download. But modern versions of OSX have the Cisco IPSec VPN client built into them.
I’m assuming you have already configured the firewall, if not see the article below;
Open your network preferences and add in a new connection > Interface = VPN > VPN Type = Cisco IPSec > Service Name = A sensible name you will recognise, (like connection to work, or home etc.)
Server address is the public IP, (or name if you have DNS setup*) of your Cisco Firewall > Enter your VPN username > I don’t put in the password, so I will have to type in in manually > Click Authentication Settings.
*For DNS you will need a static public IP, and a registered domain name. The ASA DOES NOT support DNS updates to online services like DynDNS or No-IP etc. It does support DDNS but means the server that leases you your public address is supposed to update your DNS for you, and unless you are your own ISP, and you host your own public DNS records, this wont work!
Here you need to supply the ‘shared secret’ for the VPN tunnel, and the Group Name. Your firewall admin should give these to you. If they don’t know, tell them to run ‘more system:running-config’ on the firewall and give you the shared secret and ‘group-policy’/’tunnel-group’ name for this remote VPN > OK.
Nearly every time you use DHCP, the firewall with either lease you an address from a ‘pool’ of VPN addresses, or broker the connection, and use your internal DHCP server.
Now to connect the VPN, select the icon shown, and click your Cisco VPN, (in the picture I have two).
If you didn’t put your password in during setup, you will be prompted to enter it to continue.
It does not work?
With all things Cisco, if there’s a problem your easiest way to a solution, is to run a ‘debug’ on the firewall. Execute the following two commands on the firewall, and attempt to connect again, this should point you in the right direction.
[box]
debug crypto isakmp 127
debug crypto ipsec 127
[/box]
Related Articles, References, Credits, or External Links
I always forget the syntax for this, and I’ve been meaning to publish this for a while so here you go. If you have AAA setup and people can’t log in, then the ability to test authentication against a user’s username and password is a good troubleshooting step!
Usually I’m on a Cisco ASA but I’ll tag on the syntax for IOS as well.
Solution
Cisco ASA Test AAA Authentication From Command Line
You will need to know the server group and the server you are going to query, below the ASA is using LDAP, but the process is the same for RADIUS, Kerberos, TACACS+, etc.
[box]
Petes-ASA# show run | begin aaa
aaa-server TEST-LDAP-SERVER protocol ldap
aaa-server TEST-LDAP-SERVER (inside) host 192.168.110.10
ldap-base-dn dc=TEST,dc=net
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn cn=asa,OU=Users,OU=Test-Corp,dc=TEST,dc=net
server-type auto-detect
[/box]
To test your user, (username: ttester password: Password123);
[box]
Petes-ASA# test aaa-server authentication TEST-LDAP-SERVER host 192.168.110.10 username ttester password Password123
INFO: Attempting Authentication test to IP address (timeout: 12 seconds)
INFO: Authentication Successful
[/box]
Cisco ASA Test AAA Authentication From ASDM
Log into the ADSM > Configuration > Device Management > Users/AAA > Select the Server Group > Select the Server > Test.
Select ‘Authentication’ > Enter Username/Password > OK.
Cisco IOS Test AAA Authentication From Command Line
As above, you need to know which server group, and server, you are going to test authentication against;
[box]
Petes-Router#show run aaa
!
aaa authentication login default local
aaa authorization exec default local
!
aaa group server radius RADIUS-GROUP
server-private 192.168.110.10 key 666999
!
aaa new-model
aaa session-id common
!
[/box]
Text
[box]
Petes-Router#test aaa group RADIUS-GROUP tester Password123 legacy
Attempting authentication test to server-group RADIUS-GROUP using radius
User was successfully authenticated.
OR
Petes-Router#test aaa group RADIUS-GROUP tester Password123 new-codeUser successfully authenticated
USER ATTRIBUTES
Framed-Protocol 0 1 [PPP]
service-type 0 2 [Framed]
noescape 0 True
autocmd 0 " ppp negotiate"
Petes-Router#
[/box]
Related Articles, References, Credits, or External Links
2. Know how to connect to a Cisco Firewall (CLICK HERE).
Solution
Step 1 (Add an interface to your host machine)
1. On your host PC/VM Click Start > Run > hdwwiz.cpl {enter} > At the “Add Hardware Wizard” click Next > Let it search > Tick “Yes I’ve allready connected the hardware > Next > Scroll to the bottom > Select “Add a new hardware Device > Next.
2. Select “Install the hardware that I manually select” > Next > Next > Select Network Adaptor > Next > Next > Finish.
3. Click Start > Run > ncpa.cpl > Right Click the new NIC and rename it to loopback adaptor > Then give it a valid IP on your test network. (Right click > properties > TCP/IP).
Step 2 (Configure the connection)
4. Connect to the PIX as shown in Part 1 > Give the PIX an IP address with the following commands;
[box]
enable
{Password} - Set blank by default
configure terminal
int e1
no shutdown
nameif inside
ip address {ip on test network}{subnet of test network}
write men
[/box]
5. To connect tie PIX to the Loopback adaptor you need to add some networking in the GNS3 console > Drag the cloud object into the work area > Right click > Configure.
6. Select C0.
7.Select the loopback adaptor > Add > Apply OK
Note: If you are presenting a real adaptor you will only see some uncomprehensable numbers – locate the “Network Device List” Batch file in the GNS3 directory and run it whis will de-cypher those numbers for you.
8. Drag a switch onto the workspace.
9. Click the connection tool and select “Fast Ethernet”.
10 Select the cloud (Loopback Adaptor) and drag a connection to the switch.
11. Select the PIX (Inteface e1) and drag a connection to the switch.
12. All green lights is good 🙂
13 From another machine on the network make sure you can ping the PIX to test connectivity.
Note: If you are using Microsoft Hyper-V server, you may find that the whole thing fails at this point, If thats the case, then close down the Guest machine and add and configure a “Legacy Network Card”. Bring the system back up and configure the new network card accordingly.
Also if you are in a virtual environment you can simply add another network card and get the cloud to use that instead of using a loopback adapter.
Step 3 Install and configure the ASDM (Web Inteface)
1. Set up your TFTP server and have the asdm image file ready in the TFTP servers root directory.
2. We are now going to allow connection to the PIX via Telnet – becaue the console can be a bit twichy in the GNS3 environment.
[box]
enable
{Password} <-blank be default
configure terminal
telnet 0.0.0.0 0.0.0.0 inside
passwd cisco <- sets telnet password to cisco
write men
[/box]
3. Now you can telnet to the PIX from another machine and copy the ASDM image from your TFTP server to the PIX.
[box]
enable
{Password} <-blank by default
copy tftp flash
{ip of the hosst running TFTP}
{filename of the asdm inage}
{Enter} to accept
[/box]
4. Once the file is copied over you need to let the Firewall know that its the one to use, turn on the internal http server and allow access.
[box]
enable
{Password} <-blank by default
conf t
asdm image flash:asdm-603.bin
http server enable
http 0.0.0.0 0.0.0.0 inside
write men
[/box]
The file will be copied over into the firewalls flash memory (Time for a coffee).
5. Now simply connect via the ADSM inteface – if your unsure how to do that see my article here
Using the information above you can present multiple network cards and clouds to the Virtual firewalls various interfaces (There are 5 interfaces on this firewall – its a PIX 525) – enjoy
NB Please dont email and ask me for PIX images and/or activation keys as refusal often offends – PL
Related Articles, References, Credits, or External Links
Note: PIX 515E and above, can still be upgraded to version 8.0(4) click here for details
Some people will wonder why I’m bothering to write this up, but the truth is, there are LOADS of older PIX firewalls out there in the wild, and all the PIX 501’s and 506E’s that are being retired from corporate use are being bought on ebay, or being put on IT departments test benches. This page deals with PIX version 6 if you are upgrading to version 7 or above,then you need to be on a PIX 515E (or a 525/535) and DO NOT follow these instructions, CLICK HERE. The “Smaller” PIX firewalls (501 and 506E) can only be upgraded to version 6.3(5) and the PDM can only be upgraded to 3.0(4).
Pre-Requisites
1. Before you do anything you will need a TFTP server and have it set up accordingly, for instructions CLICK HERE.
2. I suggest you backup your firewall configuration also, for instructions CLICK HERE.
3. You need to be able to get the Image and PDM versions from Cisco, you will need a valid support contract to be eligible for updates.
4. You will need a CCO Login to the Cisco Site (this is free to set up.
Solution
1. First things first; lets download the software you need CLICK HERE
Remember a CCO login is free of charge and simple to set up but to download software you need a valid Cisco contract or SmartNet.
3. For this example I’m upgrading a PIX 501 so I’m going to need a system image and a PDM file.
4. Download the files above and put then in your TFTP server root directory, then start your TFTP Server.
5. Log into your PIX firewall via the console cable, Telnet, or SSH, then enter enable mode, supply the firewall with the enable password. [box]
User Access Verification
Password:
Type help or '?' for a list of available commands.
Pix> enable
Password: ********
Pix#
[/box]
6. Now you need to copy in the new system file you do this with a “Copy tftp flash” command NOTE you can use copy tftp flash:image but it defaults to that anyway 🙂
[box]Pix# copy tftp flash[/box]
7. You will need to give it the IP address of your TFTP server and the name of the image file to copy over.
[box]
Address or name of remote host [0.0.0.0]? 10.254.254.51
Source file name [cdisk]? pix635.bin
copying tftp://10.254.254.51/pix635.bin to flash:image
[/box]
8. You will be asked to confirm, do so by typing yes and pressing enter, the file will then upload and the old image file will be erased from the firewalls memory.
[box]
[yes|no|again]? yes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!
Received 2101248 bytes
Erasing current image
Writing 1978424 bytes of image
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Image installed
Pix#
[/box]
9. The quickest way to load the new image into memory is to restart the firewall do this with a reload command, then press enter to confirm.
[box]
Pix# reload
Proceed with reload? [confirm]
[/box]
10 After the firewall has restarted log in, enter enable mode and issue a “show version” command, and you will see the new version displayed.
[box]
User Access Verification
Type help or '?' for a list of available commands.
Pix> enable
Password: ********
Pix# show version
Cisco PIX Firewall Version 6.3(5) Cisco PIX Device Manager Version 3.0(2)
{{{rest of output omitted}}}}
[/box]
Upgrade Procedure Step 2 PDM Image
1. The procedure for upgrading the PDM is almost identical, again have the new PDM image on your TFTP server’s root directory, and the TFTP server running. Log into your PIX firewall via the console cable, Telnet or SSH, then enter enable mode, and then supply the firewall with the enable password.
[box]
User Access Verification
Password:
Type help or '?' for a list of available commands.
Pix> enable
Password: ********
Pix#
[/box]
2. This time the command is copy tftp flash:pdm
[box]Pix# copy tftp flash:pdm[/box]
3. You will need to give it the IP address of your TFTP server and the name of the file to copy over.
[box]
Address or name of remote host [0.0.0.0]? 10.254.254.51
Source file name [cdisk]? pdm-304.bin
copying tftp://10.254.254.51/pdm-304.bin to flash:pdm
[/box]
4. You will be asked to confirm, do so by typing yes and pressing enter, the file will then upload and the old pdm file will be erased from the firewalls memory.
If you are locked out of your PIX firewall then you will need to do some password recovery, this procedure will reset the enable password and remove any AAA username and password settings on the PIX.
Note: If you have a PIX 520 (This has a floppy drive, and the process is different) CLICK HERE
Solution
Before You Start !
1. You need to know the software version that is running on the PIX e.g 6.3(5) or 7.0(1)
2. You need a TFTP server set up and running CLICK HERE for instructions.
3. You need to be connected to the PIX via its console cable CLICK HERE for instructions.
4. You need to download the “PIX Password Lockout Utility” that’s appripriate for your PIX i.e if your running 6.3(5) download , np63.bin or version 7.0(1) download np70.bin etc, you get get them HERE Put the file in the root directory of your TFTP server.
Procedure
1. Connect to the Firewall via console cable, then power cycle the firewall, as the firewall reboots press BREAK or ESC to interrupt the boot sequence and get to the monitor prompt.
[box]
monitor>
[/box]
2. Now the firewall has no config loaded, so you need to tell it everything it needs to know, firstly we need to set up the inside interface so we can load in the password reset utility. Use the interface command (PIX’s with only two interfaces it will default to the inside interface).
The following procedure is a complete run though on setting up a Cisco PIX Firewall (PIX 501, 506, 506E, 515, 515E, 520, 525, or 535) via the HTTPS GUI front end (PDM). Note: the PDM will only work with firewall operating systems BEFORE version 7.x.(x). Therefore PIX platforms that are 515E, 525 or 535 should be running version 7.x(x) or above and should be web managed via the ASDM. Unless you are out of support contract and are stuck with the PDM.
This assumes that the PIX has been set to factory defaults. (i.e. the inside IP address is 192.168.1.1, DHCP is enabled inside and https access has been allowed to 192.168.1.0/24). If in doubt perform a factory reset.
Note: the PDM is an OLD piece of technology, if you cant connect to it from your PC then the culprit is nearly always Java, your version is TO NEW, use the one in the download section. Also you CANT connect thought a proxy server, so bypass/disable that as well.
Solution
Related Articles, References, Credits, or External Links
