We were thinking about redundancy options for CCIE.PL today. There are few restrictions we have there, both came either from policy or our personal thoughts about several aspects of paid services and sharing admin access. But simply we are thinking how to automate failover in case our primary server or database have problems. Easiest solution would be to use Cloudflare free tier service but let’s say we don’t want to do this now. So we were looking on the other options and there was an idea that maybe we can use cloud load-balancer for on-premise services. First thought – it’s brilliant. On second thought – definitely that idea was wrong. Let me show you why.
Hardware failures happens. If you have active service contract you’ll get new device from Cisco with same hardware parameters. One thing you don’t know is which version of software will be installed. In almost all cases it’s not the one you are using. Installing new firewall firmware on ASA is not a problem but what if you’re running SourceFire Management Center version 6.2 but your device came with 5.x or 6.0 firmware on SFR module? Well, prepare for process that will take few hours – you need to perform recovery procedure which is one of the ways of upgrading SourceFire.
Most common cases when we have to use recovery procedure for SFR are:
- Problems with booting the SFP module after upgrade performed from Firesight Management Center
- First software installation on SFR (in example when we just put SSD drives in our ASA to get benefits from Sourcefire NGIPS)
- Need to upgrade firmware but our module cannot be registered in Firesight Management Center due to firmware mismatch
Last case is the one usually happening when we get new device during RMA process. Each Firesight Management Center have list of compatible firmwares that are supported on modules and unfortunatelly backward compatibility is not full. If you run one of the most common version 6.1 or 6.2 you need to have your modules in at least 6.1 version. Recovery process require that whole memory is erased and new firmware installed.
One reader asked me few days ago following question when he had problem establishing the failover in his lab: “I’ve tried to create ASA failover pair on VIRL and it was not working. I’ve looked through manual and VIRL forum for the solution. I believe that failover is supported configuration on VIRL. I think my configuration is correct, nodes can ping each other but I still cannot establish failover relationship”. Configuration he made was correct except he forgot about one thing – interfaces numbers are important when you setup failover using ASAv.
Cisco VIRL uses ASAv image for virtual firewalls. This is same image that you use in production on ESXi. That means all restrictions applies also to virtual firewall if you run it on VIRL. In this image we must configure failover link using interfaces GigabitEthernet0/8. It’s clearly stated in documentation. If we use any other interface the configuration will be accepted but failover never established.
failover lan unit primary failover lan interface Fail-link GigabitEthernet0/8 failover replication http failover link State-link GigabitEthernet0/7 failover interface ip Fail-link 192.168.255.253 255.255.255.252 standby 192.168.255.254 failover interface ip State-link 192.168.254.253 255.255.255.252 standby 192.168.254.254 failover ipsec pre-shared-key 0 FailoverKey failover
We also need to remember we can’t configure Active-Active failover. This mode is not supported so we have to stick to Active-Standby model. It’s direct result of lack of support for virtual contexts so remember about it as well.
I’ve said during several conferences where I had a privilege to be a speaker that clouds are one of the futures of computing along with DevOps/SysOps and Machine Learning. But there is no computing if you don’t have the data to compute or you have no way to send it to the cloud in reliable and secure way or you don’t have cloud infrastructure to perform computation. That’s why we need to take a look how to setup VPN between Juniper SRX and AWS Cloud.
I think that hybrid cloud will be the model how many of computer system will work in net few years. Private clouds are not scalable and public clouds cannot address all needs of current systems. So hybrid mode is a solution. But it requires reliable and easy to setup and maintain ways to connect on-premise resourced to public cloud. The technology is here and it’s called VPN.
Microsoft Operations Management Suite is nice, and in some cases free, tool to manage and search through logs. But it’s dedicated to Windows and Linux operating systems by default. In many environments, especially those most secure ones, huge amount of logs are generated by network devices. Firewalls placed on the edge between Internet and DMZ zone quite often are set up to log all denied connections. Those firewalls can produce significant volume of logs that need to be searched and analyzed. Microsoft Operations Management Suite seems to be perfect tool for that but there is no native support of such feature. But we can implement this doing small workaround. Let’s look how to add network device to Microsoft Operations Management Suite using syslog.
Collecting and processing logs from all systems and network devices can be a nightmare for any systems admin. Searching through them and performing security audits can be a nightmare for security team if collector engine is not powerful enough to process queries in efficient time. Microsoft Operations Management Suite is interesting solution to answer both those problems and add much more analysis giving administrators visibility and control across on-premise and cloud installations.
Microsoft Operations Management Suite runs in Azure which means it’s extremely fast in processing the data. Millions of records are not problem for OMS so we can get Insights and Analytics of what is happening on our servers or workstations, detect and respond to threads or apply proper protection or even put in place some automation in controlling. It’s quick to setup and for many users it can be for free!
It’s been 7 years since I’ve started this blog. It was 6 months after I gained my CCIE certification and thought it will be good place to share some of interesting technical stuff from projects I’ve been working on. I was then deep into Cisco world due to fact company I was working for was Cisco Gold Partner and majority of projects were done using Cisco products. There was a gap in posting when I had little time to focus on blog but in October 2016 it was back in game. In little refreshed form in term of content.
What’s new on IT Playground?
Now it’s time for little rebranding. As you may noticed content is already not as Cisco-oriented as it used to be. I’m doing different projects now, there are different customers I’m working for, technology moves forward as well. There is more talk about SDN, DevOps, cloud technologies, virtualization etc. CCIE is very important and valuable certification for me but Cisco is not the only vendor worth focusing on.
Therefor I’m moving from ‘CCIE Playground’ to ‘IT Playground’.
I received very good feedback about latest posts on REST API so I’ll still try to show how to real new technologies and fill posts with practical examples. I will focus on design considerations that will be more vendor independent. Security aspects of solutions will be important as well.
Blog is now available under link https://blog.it-playground.eu
I hope you’ll like it 🙂
Have you ever tried to run ASAv image on Amazon Web Services (AWS)? Yes, in Marketplace you will find supported image of this firewall (which is actually great thing because you can run it in BYOB model where you use unlicensed mode for testing the features. Same way as you can do on your ESXi.
Deployment is easy with the creator of EC2 instance, just few clicks and there it is. Except small problem – on latest release of 22.214.171.124 I was not able to connect to management interface via SSH. It should be possible by using key assigned to instance during creation but no matter what I’ve done it always asked for password.
There is small but nice workaround of this problem that also enables HTTPS access to ASAv. During the instance deployment we should put zero-day configuration that will be implemented on ASA. In documentation we even have proposal on such config which we further modify by adding HTTP/HTTPS access, additional user account, enable password and aaa local authentication.
The final zero-day configuration should look as below
interface management0/0 management-only nameif management security-level 100 ip address dhcp setroute no shut ! same-security-traffic permit inter-interface same-security-traffic permit intra-interface ! crypto key generate rsa modulus 2048 http server enable http 0.0.0.0 0.0.0.0 management ssh 0 0 management ssh timeout 30 username admin nopassword privilege 15 username admin attributes username cisco password cisco privilege 15 enable password cisco aaa authentication ssh console LOCAL aaa authentication http console LOCAL service-type admin
This way we will be able to connect to ASAv instance via ssh/http using local accounts.
Why Swift? Because I got bored one evening 🙂 Well, that’s partially true. I’ve heard good opinions about Swift language from professional developers. It’s now open language available for many platforms, not only Apple products. I also like to try new things and was curious if learning at least basics of new language by myself would be hard and how quick I can do that. Also Apple was very helpful because of nice tutorial from Apple Developers which show step by step how to use XCode, build application interface and connect code to objects. There are many examples on Internet, I think the hardest thing at the beginning was to understand some language semantic constructions and get familiar with API of system libraries. Also, if you ever start programming in Swift remember that current version is Swift 3.0, but many examples on the web are from older versions and won’t work without minor or major changes to the code.
So what was my concept of an application? Easy, I just wanted to get information about firmware version installed on ASA. But of course if you have idea of other apps then sky is the limit 😉
Apple care about users privacy and security quite well. Of course it’s a matter of opinion but Apple put strong focus on encryption and peer authentication. In 2015 Apple introduced App Transport Security (ATS) as part of their Network Framework With every release they are putting more and more responsibility on developers and content operators to provide proper traffic encryption proper certificate signing and chain etc. That means if application is trying to connect to HTTP server that does not support latest TLSv1.2 connection should fail.
There is no doubt that ATS is good for end users and that’s right direction every corporation should follow. But switching to TLSv1.2 is not something that can be done just like that, obtaining signed certificate expensive option, especially for development environments or if you are writing apps to just test something or for fun. Self-signed certificates are the solution for such cases but there are few problems that we can encounter.