Connecting the world…

path

Cacti – PA 3.0 wrong path for plugins

After upgrading a CactiEZ installation to cacti 0.8.7h including PA 3.0, I had some problems with the different plugins. The default path for the plugins was configured incorrectly. The plugins were looking in the wrong directory for their images. In the httpd error log I see the following errors.

[root@localhost html]# tail -90f /etc/httpd/logs/error_log
[Wed Jul 18 07:52:19 2012] [error] [client 10.254.60.18] File does not exist: /var/www/html/plugins/monitor/include, referer: http://10.254.10.20/plugins/monitor/monitor.php
[Wed Jul 18 07:52:19 2012] [error] [client 10.254.60.18] File does not exist: /var/www/html/plugins/monitor/include, referer: http://10.254.10.20/plugins/monitor/monitor.php

The problem can be fixed by adding the following line to the include/config.php file.

$url_path = “/”;

Now all plugin pages are displayed correctly.

Microsoft ISA publishing – it’s all in the “path”

I have installed multiple reverse proxy servers based on Microsoft ISA 2006. These reverse proxy servers are mainly deployed to publish services like Outlook WebAccess, PDA synchronization, SharePoint or regular websites. Services like Outlook WebAccess are published using secure session protected by SSL certificates. Microsoft ISA server uses “Listeners” to match and intercept traffic from public users.

I have seen multiple ISA publishing rules with only match traffic when the user enters the specific URL in the browser. Let’s take OWA as an example. When users would like to access OWA, they need to enter the following URL: https://webmail.booches.nl/owa. The base URL is webmail.booches.nl and users need to add /owa manually, because internally the Exchange server is configured with a virtual directory called owa. Sometimes I see Listeners configured for HTTP and HTTPS and all HTTP traffic is redirected to HTTPS.

Is this solution user-friendly? What happens when the users makes a typo and enters http://webmail.booches.nl/ower? I try to configure the publishing rules to be user-friendly and I always configure separate Listeners for HTTP and HTTPS traffic. When publishing OWA I configure 3 firewall policy rules.

  1. 1. The first rule redirects all HTTP traffic (http://webmail.booches.nl/* to https://webmail.booches.nl/owa;
  2. 2. The second rule intercepts all the OWA traffic (https://webmail.booches.nl/owa);
  3. 3. The third rule redirects all HTTPS traffic (https://webmail.booches.nl/* to https://webmail.booches.nl/owa);

The first rule uses a Listener, which is configured for HTTP-only traffic and doesn’t use authentication. The firewall policy is intended for All Users and there is no authentication delegation.

action-http Action for HTTP and HTTPS redirect is to block the request and redirect the request to the correct URL for OWA
Listener-http The Listener for HTTP is configured without Authentication method and the rule is intended for All Users
path-http The public path contains /*

The second rule uses a Listener for HTTPS-only traffic and uses HTML Forms Authentication with LDAP, RADIUS or another authentication method. The associated firewall policy is intended for all Authenticated Users and uses authentication delegation based on Basic Authentication or Negotiate (NTLM / Kerberos) authentication.

Listener-owa The Listener for HTTPs is configured with FBA as authentication method and the rule is intended for Authenticated Users. The authentication delegation is configured for Basic Authentication or Negotiate
path-owa The public path configuration contains the appropriate Exchange virtual directories

The third firewall policy uses the same Listener as the second rule, but doesn’t use authentication delegation and is intended for all users. The configuration of the path, users and authentication delegation is the same as the first rule.

When you need to publish additional services, like ActiveSync or Outlook Anywhere, you have to add the specific publishing rules between the second and the third rule, so the redirection doesn’t mess up your publishing.

This setup is very user-friendly, at least that’s my opinion. The public user only needs to type the base URL (webmail.booches.nl) correct and he is always redirected to the OWA sign-in page. Service like ActiveSync or Outlook Anywhere are automatically configured to use the correct public path (/Microsoft-Server-ActiveSync or /rpc).

Cisco ASA & ESX: strange ARP behavior

Last week I had a very strange problem with a Cisco ASA firewall. The firewall is configured with multiple interfaces, including a DMZ interface. There are multiple servers in the DMZ. These servers are physical and virtual servers. The virtual servers are VMware servers in a blade environment.

I configured the feature

ip verify reverse-path interface DMZ

to prevent spoofing to occur. I also configured a transparent static NAT rule between the Inside network and the DMZ network and multiple static NAT rules between the DMZ network and the Outside network. I left the proxy ARP feature configured with its default settings.

The customer was complaining about log in problems and connectivity problems on the DMZ servers, especially between different DMZ servers. I have done some research and noticed that all problems were related to DMZ servers in the blade environment.

I started some connectivity test and noticed some strange ICMP behavior on the specific servers. When I started a ping from one DMZ VMware server to an other DMZ server on the same ESX host, the first ping responded with an echo-reply, but consequent pings failed. Looking at the ARP table of the server, I noticed that the firewall responded with its own MAC address for every ARP broadcast.

Looking at different forums on the Internet, everybody is speaking about the proxy ARP feature and that you should disable this feature. By default proxy ARP is enabled and I always leave it enabled. Till now I never had this problem. After disabling the proxy ARP feature for the DMZ interface

sysopt noproxyarp DMZ

the problem was solved, because the firewall doesn’t respond to the ARP queries, except for its own interface. Digging a bit deeper on forums, I never found one thread who explains why the proxy ARP feature should be disabled to solve this particular problem.

In my opinion this problem is related to the VMware environment, because I don’t have these problems with physical DMZ servers. So it is strange why the DMZ servers on the same ESX hosts cannot see each other and why does the firewall respond to the ARP queries?

In the near future the blade environment (ESX hosts, network configuration and SAN configuration) is changed, so I hope to find the exact cause and solution of the problem. Does anybody else have some suggestions??