Reading up on Cisco IOS 12.4.20T, I got excited. It has some new features, which could really come in handy.
The feature that appealed to me mostly was group objects for Access Control Lists. This means you can, for example, make a group of non-sequential hosts/IP-addresses, and use that group in the firewall; as opposed to making one entry per host/IP-address. It can also be used to make a group of protocols.
So, I installed the firmware on our Cisco 1841, and started to experiment a bit; but couldn't get it to work. Reading up on the documentation, I found out that it only works on a named ACL, and not on a numbered ACL. That problem was fixed quite easily, but it still refuses to work. Let's say for example I make an object group with hosts and an object group with protocols, and then apply a simple ACL to it.
Object-group network test_hosts Host 192.168.0.4 Host 192.168.0.18 Host 192.168.0.66 End Object-group service test_ports Tcp 22 Tcp 25 Tcp 110 End Ip access-list extended test_acl 10 Permit object-group test_ports object-group test_hosts host 192.168.0.1 20 Deny ip any host 192.168.0.1 End
You would logically assume that only 192.168.0.4, 192.168.0.18 and 192.168.0.66 would be able to connect to 192.168.0.1 using SSH, right? Exactly, that's what I thought too... unfortunately it's not the case. Yet according to the configuration guide, it should work.
During the experimentation process I did manage to clean up the firewall configuration quite a bit, removing redundant/overlapping firewall rules, and grouping sequential IP-addresses using the old method. I've installed the latest "production" firmware on the router, and will continue to experiment with the object-groups over the next few weeks. It sucks though, that I can only work on the firewall on Tuesday nights, after work hours.
I've always been a big gadget junkie. I love electronic toys (no... not that kind, you pervert), so when one of the sales guys at work had two mini laptops (ACER Aspire One and MSI Wind U100) on demo for a customer, I couldn't help drooling a bit.
Speed: They both have the same CPU, but the ACER definitely has some more speed in it. This is most likely due to the fact that the ACER runs a trimmed down Linux distribution, and the MSI runs a fully fledged Windows XP.
Sound: Both are quite soft, but that's no surprise. After all you can't stuff big speakers into a small laptop. But overall, I think the MSI has slightly better sound.
Webcam: The ACER wins here, without doubt. The webcam on the MSI was too bright for my taste, which resulted in an off-colored image. I looked more like a zombie than a human being, and as far as I know that's not the case (...yet).
Screen: The MSI has approximately 1 inch more screen surface, but has the same resolution as the ACER (1024 x 600). The MSI has a matte non-glare screen, where the ACER does have a glossy screen. The MSI has a much brighter screen, as you can see on the photo, but still the ACER wins as far as I'm concerned. The screen is less bright, but due to the glossy coating and the smaller size, it just looks sharper somehow.
"zOMG how cute!"-Factor: Without doubt, the ACER wins here simply due to the fact that it's also available in baby pink; and that's indisputable.
Extra features: The ACER has a built-in 3G modem, which means you can get a mobile internet subscription and stuff the simcard right into the laptop. No USB plugs, no Bluetooth receivers... you just stuff the card into the laptop and you got high speed mobile internet just about anywhere.
All in all, I liked the ACER more than the MSI, due to its features and finish. I'm not too sure I like the Linux distribution too much. For most users it does its work perfectly... but I'm not a normal user, I'm a geek. So I want somewhat more functinality. Fortunately, the ACER also comes in a version with 1GB memory and a 120GB hard disk with Windows XP on it. I'm very curious about that one.
Microsoft Windows... the world's most used-, and probably the most flamed at, Operating System in the world. It's packed with many nifty features, funky eye-candy and unfortunately also many, many bugs.
A quick search on Google told me that this happens when some Dynamic Link Libraries are no longer registered with Windows XP. What the hell? It's a fresh install, I only ran Windows Update, and the system is broken... nice going Microsoft! Fortunately, the site also told how it can be fixed, so without further a due...
When your Windows Update suddenly stops working without any errorcode, just open a command prompt, and enter the following commands:
regsvr32 wuapi.dll regsvr32 wuaueng.dll regsvr32 wuaueng1.dll regsvr32 wucltui.dll regsvr32 wups.dll regsvr32 wups2.dll regsvr32 wuweb.dll
Then re-run Windows Update, and it should work again
In a previous entry, I wrote about some of the good and bad things about my workplace. The "good" in the company gained another boost today.
*slurp* A very good idea indeed
At first, it seemed like we didn't have any casualties due to the air conditioner accident last week. Unfortunately, I was mistaken. One of the servers actually did die, slowly and painfully. May her soul rest in peace.
The server that died was an old one, and wasn't fully installed yet, so that's a bit of luck. Another bit of luck is that I still had the Hewlett Packard DL140 G3 on the shelf, which was originally supposed to become the new Microsoft ISA Server. I've decided to use that server as a replacement for the deceased one.
As I wrote several times before, IT can be quite retarded. Manufacturers that don't supply drivers for their own hardware, people that turn off business critical cooling systems, etc... And, what do you know? I've found another retarded thing: Microsoft Exchange Server 2007.
Since I had to reinstall the server from scratch anyway, I thought it would be a good idea to upgrade this particular server to Exchange 2007. I downloaded the 6GB large ISO file from MSDN, and started the installation. But hey, wtf? The ISO said "This program is not suitable for your server's architecture". So, I looked on the MSDN site and saw 2 ISO files:
- Exchange Server 2007 Standard and Enterprise Editions
- Exchange Server 2007 with Service Pack 1 Enterprise and Standard Editions (x64) DVD
One clearly states X64, one clearly doesn't. Of course, Murphy's Law still applies here, and it turns out that both are for 64 bit architecture. So there is no 32 bit version of Exchange Server 2007? Oh yes, there is... But it's a test/demo version! So apparently Microsoft got it into its head that only 64 bit servers can run- and/or upgrade to Exchange Server 2007! Wtf dude?! Back to Exchange 2003, it is then...
Sometimes... you just want to grab someone's throat and do them and the rest of the world a favor by releasing them from their stupidity.
Let me explain the situation: At work we have this smallish room that acts as server room, but also hosts some gauges for the gas, water, electricity, etc. And also, there's a machine in the room that automatically folds letters and stuffs them into envelopes. Unfortunately, this machine is located exactly under the air conditioner.
So... whenever one of my co-workers has to work on the envelope folding machine, he has the full cold winds from the air conditioner in his neck, which he doesn't like. So this co-worker, which we shall refer to as "Mr. Smarty-pants" from here on, got the bright idea of turning off the air-conditioning when he's working on the envelope folding machine. As we all know, Murphy's Law never rests, and so last Friday Mr. Smarty-pants forgot to turn the air conditioner back on when he was done folding envelopes.
So today when my boss arrived at work, he noticed that some servers were unavailable, went to see what was up and was welcomed with a nice steaming hot sauna in the server room. Upon my arrival, the first thing I did was power down a couple of servers, and turn the air-conditioning up a few notches.
A couple of hours later, the temperature in the server room was acceptable again, and the servers could be booted up for diagnostics. I pray to the holy gods that we have no serious damage or loss of data.
So, remember kids... Air conditioners in server rooms are there for a reason. Do not turn them off!
The new firewall, a Cisco 1841, has been running stable for a couple of days now, and I must say that I'm pretty content with it. When the Cisco was subjected to the live environment on Tuesday, there were 2 minor problems to tackle, but they all turned out all right.
The first problem was that the VPN didn't seem to work. Later on this turned out to be a human error; some sloppiness on my side. After I decommissioned the old firewall Tuesday night, I tried to connect using VPN and failed. I assumed it was firewall related, and decided to read up on it before trying to fix it. A 2nd look on Wednesday told me that the VPN service disappeared as a whole. After I removed ISA Server 2006 from the machine, I didn't keep into account that it would also remove the VPN facility. A quick reinstall fixed that problem.
Secondly, the PHP programmers use ZEND studio, a PHP development suite that can debug live websites. For this feature to work, some ports need to be forwarded, which is no problem on its own. The problem is, that these ports need to be accessible for both the PHP programmer's workstation, as an external source; but the firewall doesn't allow internal network traffic to access the external IP Address. This is not a firewall policy, but a default restriction. Some routers have this enabled, some don't; the Cisco is one of those that don't. This can be solved using a NAT Virtual Interface, which basically makes a loop around the firewall. This does however mean that I have to heavily modify the configuration, which is running stable at the moment. I've got a Cisco 828 at home which I will use as a test firewall for this.
In the meantime I've created a workaround for the problem by using a method called "DNS Spoofing". On the public DNS I've created a record that points to the external IP. On the internal DNS I've created the same record that points to the local IP of the programmer's workstation, and then entered the DNS name in the configuration of ZEND studio. When the programmer clicks the "debug" button, the external source resolves the name via the public DNS Server and ends up at the external IP address, while the programmer's workstation resolves the name via the local DNS Server and ends up at this internal (port forwarded) IP address. This works fine, and takes some pressure off my back for the NAT Virtual Interface configuration challenge.
I've definitely decided to kick Microsoft ISA Server 2006 to the side. I placed a support ticket at Microsoft Tech Support, but even they don't seem to have a clue.
The technician sent me an e-mail requesting some information. I downloaded some tools from their website, and e-mailed the results back to Microsoft. First they suggested that the Kaspersky Anti-Virus plug-in was causing trouble, and that completely removing it should fix the problem. I had my doubts, but followed Microsoft's advice. I removed it, tested it, and it still gave the same result. The next suggestion that Microsoft sent back, was to increase the connection limits, since the log file showed some blocked connections. I increased the connection limits by a factor 100, but still the result was still the same (though it did solve the log file entries :P).
While Microsoft was busting their balls over how to fix the ISA Server 2006, I took a peek at the Cisco 1841. At first, I couldn't get the thing to connect. I gave it an external IP address, 2 DNS servers and a default route; but the bastard steadily refused to connect. After some thinking and pondering, it suddenly popped up in my head. I had forgotten one simple command:
router# ip routingAfter that small problem was solved, it was a piece of cake. Right now I have the Cisco set up in a simple NAT configuration, with a basic firewall up and running. First performance tests gave me a big smile on my face, and totally numbed any annoyance caused by the ISA Server problems. Monday I will finish up the firewall configuration, so I can submit the Cisco to a live environment test on Tuesday.
One of the major benefits of Cisco routers is that all types use the same Operating System. So if the 1841 ever breaks down, I can copy the whole configuration "as is" to any other Cisco router and it will work without any major adjustments (At most I would have to chance the interface names and vlan configuration). Even though the Cisco 1841 is usually used for routing from Ethernet to E1 WAN connections, it can of course also be used for routing between two Ethernet interfaces. On paper, the Cisco has a firewall throughput of about 130Mbps, which is more than enough for our 20Mpbs internet uplink. I just need to find some 19" rack mounting brackets for it, and we're set.
The decision to use the Cisco as firewall also frees the Hewlett Packard Proliant DL140G3 up for other uses. I will probably use it as a central logging facility for all the routers, switches and other appliances. And since all our workstations and servers are Hewlett Packard anyway, I might just as well run Hewlett Packard Systems Insight Manager on it for monitoring. I'll turn the server into a centralized Systems Management and Monitoring Center, as you may call it .
Anybody who is even remotely familiar with Murphy's Law knows exactly what this post is about. Yesterday I replaced our old firewall with a brand new one; and for a while it actually seemed like the transition went flawless. Obviously I was deceived.
The server, running Microsoft ISA 2006 on Windows 2003, ran perfect for 2 weeks in a test environment. Aside from adding some rules to the firewall, the configuration of ISA 2006 was pretty much "out of the box". It ran fine for 2 weeks, and even yesterday after it was implemented in the live network, it seemed to do its job near perfect (minus some small VPN issues, as mentioned before).
Today came the real test. The entire company would be using the firewall and proxy, and for a moment it seemed to be doing fine. But then something strange happened. Where the firewall would keep running, the proxy service seemed stop and start every few minutes. Since the majority of business done by the company is done online, an unstable proxy is pretty much a horror scenario. You know what that means... a stressed out system administrator. For me the situation was even more stressed than normal, because I couldn't figure out what was wrong. There were no entries in the log files, no error messages, and no frozen processes... nothing...
After a couple of hours I decided enough was enough and made a workaround solution. I dashed down to the warehouse, grabbed the first internet access router I could find and put the little thing to use as the company's main internet access point. The thing manages to keep up quite well, even though it is just a consumer product that is designed to provide secure access for 2, maybe 3 computers; certainly not a complete office with a dozen servers and 40-something workstations. The pressure was off my back, and I finally had some time to try and find a permanent solution.
I've got a support ticket running at Microsoft Tech Support (we're Gold partner after all), and they are offering help, but I'm starting to get tempted to forget the ISA server and find a different solution. 
One of the network switches at work was giving some weird and random behavior. On random intervals, it would disable a port, and enable it again a second later. This is, of course, undesirable. Since I couldn't find any problems in the configuration, I decided it would be best to replace it.
I also put a new firewall into service. In the old situation, one server was doing pretty much everything. It was firewall, exchange server, fileserver, DNS server and domain controller. This forms a single point of failure. If the server crashes, you lose all internet access, you can't access your mail, and you can't even log on anymore. Obviously, you don't want that to happen, so it is vital to shift some stuff around and distribute functionality over multiple servers.
First priority was the firewalling service. We had a Hewlett Packard Proliant DL140 G3 standing in the warehouse, that was returned by a customer at some point. During the process of installing Windows 2003 on It, I began to understand why.
"Ok.. Now all I need is a floppy disk, and I'm on the move!", I ignorantly thought to myself. Right... Though it kind of sucks if you can't find a singly floppy anywhere in the building. Tarek, an intern, said he had some floppy disks at home and drove off during lunch break to fetch some. Unfortunately, they didn't work. So, the server was pushed aside for the day. The next day I brought some old floppies (they still had DooM on them), and downloaded the proper drivers from the Hewlett Packard website. Windows 2003 still wouldn't recognize the drives, and even after trying pretty much any driver I could find on the Hewlett Packard support website, the server still wouldn't budge.
The solution was found at a 3rd party. I downloaded drivers from the website of the chipset manufacturer, and behold! Windows 2003 actually recognized the drives. Hurray, I could finally install the server!
Now then... what kind of retard puts drivers on its support website, that actually don't do jack shit ? Hewlett Packard sure lost quite a bit of credit on my side for its sloppy customer support on this server. Normally, the Hewlett Packard Proliant servers have excellent support, but this server is obviously a budget server, and Hewlett Packard didn't pay much attention to the details. Very sloppy, Tssk tssk...
After the server was installed and fitted with the proper software, the thing ran like a charm. I tested it thorrougly for about a week by running it parallel to the old firewall, and making some devices use it as the default gateway; instead of using the old firewall. Everything seemed to work as it should be, so i decided that the time was right to do the transition. Since tonight was soccer on TV (European Championship 2008), and nobody would be at the office anyway; I figured it was the perfect night to replace the firewall and do some final tweaking and fine tuning. The transition went nearly flawless, minus some small issues with the port forwarding for the VPN server; I'm fairly sure I'll get those solved tomorrow, though...