Booches.nl

PIX Failover not working

Today I received the question why a PIX failover configuration wasn’t working. The customer accidentally disconnected the power cable from the primary PIX firewall. The secondary PIX firewall became the active one, but multiple DMZ segments weren’t working anymore. After rebooting the PIX firewall and making that the primary one again, the DMZ segments were reachable again.

I started looking at the failover state of the firewall. Entering the commando show failover on the primary PIX resulted in the following output:

This host: Primary – Active
Active time: 5430735 (sec)
Interface outside (1.1.1.1): Normal
Interface inside (2.2.2.1): Normal
Interface DMZ01 (3.3.3.1): Normal
Interface DMZ02 (4.4.4.1): Normal (Waiting)
Interface DMZ03 (5.5.5.1): Normal (Waiting)
Other host: Secondary – Standby Ready
Active time: 5235 (sec)
Interface outside (1.1.1.2): Normal
Interface inside (2.2.2.2): Normal
Interface DMZ01 (3.3.3.2): Normal
Interface DMZ02 (4.4.4.2): Normal (Waiting)
Interface DMZ03 (5.5.5.2): Normal (Waiting)

Interface DMZ02 and DMZ03 were the problem interfaces.

After doing some simple ping test, I noticed the problem interfaces couldn’t ping each other. Looking at the output above the interfaces are in Normal (Waiting) state. Searching the internet resulted in the following:

Failover does not start to monitor the network interfaces until it has heard the second “hello” packet from the other unit on that interface. This takes about 30 seconds. If the unit is attached to a network switch that runs Spanning Tree Protocol (STP), this takes twice the “forward delay” time configured in the switch (typically configured as 15 seconds), plus this 30 second delay. This is because at PIX bootup and immediately following a failover event, the network switch detects a temporary bridge loop. Upon detection of this loop, it stops forwarding packets on these interfaces for the “forward delay” time. It then enters the “listen” mode for an additional “forward delay” time, during which time the switch listens for bridge loops but not forwarding traffic (and thus not forwarding failover “hello” packets). After twice the forward delay time (30 seconds), traffic resumes flowing. Each PIX remains in “waiting” mode until it hears 30 seconds worth of “hello” packets from the other unit. During the time the PIX is passing traffic, it does not fail the other unit based on not hearing the “hello” packets. All other failover monitoring still occurs (that is, Power, Interface Loss of Link, and Failover Cable “hello”).
Source

Here they are talking about the STP configuration. I couldn’t imagine that the problem is lying in the STP configuration. I started tracking the mac-address on the switches to check the physical patching.

The problem was found directly. The patching of the secondary PIX wasn’t correct. The customer had swapped the two interfaces resulting in patching them in the wrong VLAN. After swapping the patches the failover state functions normally, looking at the output below:

This host: Primary – Active
Active time: 5430735 (sec)
Interface outside (1.1.1.1): Normal
Interface inside (2.2.2.1): Normal
Interface DMZ01 (3.3.3.1): Normal
Interface DMZ02 (4.4.4.1): Normal
Interface DMZ03 (5.5.5.1): Normal
Other host: Secondary – Standby Ready
Active time: 5235 (sec)
Interface outside (1.1.1.2): Normal
Interface inside (2.2.2.2): Normal
Interface DMZ01 (3.3.3.2): Normal
Interface DMZ02 (4.4.4.2): Normal
Interface DMZ03 (5.5.5.2): Normal

This proves again how import correct patching is!!!!!

New look and feel!!

I updated the theme I use for my blog and I noticed that the RSS feeds weren’t working for me anymore. I had to subscribe again before the RSS entries were updated again.

So for those of you who have subscribed to my RSS feed, maybe you have to unsubscribe and subscribe again to get new post updates.

By the way, who do you like the new look. All the credits go to Corry Miller for developing the RockinBlue WordPress Theme.

MAC Authentication Bypass

NAC (for Cisco – Network Admission Control) or NAP (for Microsoft – Network Access Protection) in conjunction with 802.1x will be standard for authenticating network components and allowing them access to the network. At least in the future.

Currently their aren’t a lot of companies how are using NAC in the network. Techworld released an article about the caveats of NAC.

In the near future I am going to implement dynamic switch port security on a network. I would like to use 802.1x, but not all components are supporting 802.1x at the moment. While searching for documentation about the configuration of 802.1x, I found a backup authentication method for 802.1x with the name MAC Authentication Bypass (MAB). If a network component doesn’t support 802.1x, it uses its MAC address for authentication.

Much like the Guest-VLAN, MAB operates based on an 802.1x timeout condition. After a switch port can ascertain that an 802.1x supplicant is not present on the port, it falls back to checking the MAC address (which is an authentication technique of lesser security). After timing out 802.1x on the port, a MAC address can be learned by the switch through classic MAC learning techniques. after a MAC address is learned by the switch, it can then be authenticated by RADIUS initiation. The MAC address is used as username AND password in the RADIUS request. This means you should create an account with the MAC address as username and password.

I found some documentation about on the Cisco website, but I don’t have a suitable router at home for testing MAB. Looking at the PDF you should use the following commands in global config and on a switch port:

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
interface FastEthernet0/1
switchport access vlan 2
switchport mode access
dot1x mac-auth-bypass
dot1x pae authenticator
dot1x port-control auto
dot1x control-direction in
dot1x timeout tx-period 1
dot1x max-reauth-req 1
spanning-tree portfast
spanning-tree bpduguard enable

When I have the appropriate equipment, I will do some testing on MAB. But I am curious if somebody already tested MAB or maybe already implemented MAB? What are the caveats during testing and/or implementing? How does MAB work in conjunction with features like Wake-On-LAN, DHCP and Voice VLAN’s?

Check the follow up article for more configuration or the latest article about MAB and MDA in an IP Phone environment.

PDA Active Sync – Invalid Certificate

The usage of Pocket PCs (PDAs) becomes more and more a default feature for business. The last months I have installed quit some Windows ISA 2006 servers for Reverse Proxy purposes. I have installed them normally for webmail only, but lately I have added the Microsoft Active Sync feature.

The Pocket PCs connect to the organization via UMTS, GPRS, USB with laptop or whatever with an internet connection. Today I had the same job on the schedule: Enable Active Sync for Pocket PCs.

I thought by myself: EASY JOB, but NOT. After configuring the ISA reverse proxy I used a Pocket PC emulator to test the Active Sync features. I received the following error message when synchronizing:

I found this a strange message, because clients use the same URL as the Pocket PC for accessing their webmail and they never receive an error message for an untrusted certificate.

The used certificated is issued by Equifax Secure Global eBusiness CA-1. This is a common and one of the better CA’s.

I had to dig deeper into the problem. I tried to install the certificate on the Pocket PC, but no luck. I searched the internet and found a tool called Microsoft Exchange Server Disable Certificate Verification. You can find an executable here, which can be used when using the Pocket PC in conjunction with a PC through USB. I also found a similar tool to install on the pocket PC, this is called AS_Cert_OFF.cab. The tool wasn’t the solution to the problem, so I had to dig deeper.

I was thinking way to complex, the problem was fixed by requesting a new certificate. The used certificate didn’t support Pocket PC. Comparing the different SSL certificates on QuickSSL.com I noticed I had to use a QuickSSL Premium certificate. This certificate supports popular mobile devices and smartphones.

After generating a CSR, requesting the certificate and installing the certificate on the ISA server, the connection and synchronization works like a charm. At least for the most PDA’s. Some PDA’s received the following error 80072f7d. After searching some forums, I found the solution in adding a registry key. I added the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows CE Services]
“AllowLSP”=dword:00000000

After adding the key to the registry, all Pocket PC’s synchronized perfectly.

Another colleague starts blogging again

Yep, there is another one. His name is Ivo Beerens. Ivo is another VMWare consultant at Ictivity. His blog contains post many categories, but is mostly related to VMWare. His blog can be found at IvoBeerens.eu.

A couple of outtakes from his blog:

directly access a VDM Connection Server by using the hostname of the VDM Connection Server, you must specify an externally resolvable name for the VDM Connection Server. If the VDM Connection Server is accessed from the Internet, set the name to something [...] Source

i did a VMware VDM implementation. When using a VDM security server i the DMZ you need to open the following ports: [...] Source