natacado's questions

I'm looking at setting up a DMZ behind a Cisco ASA that will contain a large number of HTTP front-end load balancers and SSL offload services - over 100 IPs, concentrated on a smaller number of hosts.

In the past I've kept all the hosts on RFC1918 private IPs, and added static mappings (IP-by-IP) for each service I'd normally expose in a DMZ. This has gotten annoying as we've started adding additional DMZ IPs at a fast enough rate that it's becoming annoying setting each one up individually. I'd like to change it so that an entire DMZ subnet is setup to allow HTTP and HTTPS from outside --> dmz, so that the load balancers can just grab new IPs as necessary without updating the ASA configuration every time.

What I'm wondering now is whether it makes sense to have the DMZ be on a RFC1918 subnet and use a static NAT across the entire subnet, or whether I should just let the DMZ be my allocation of external IPs directly, and rely solely on access-lists and identity NAT/NAT exemption.

Some crude ASCII artwork:

Example using direct outside IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
                  +-----> DMZ (1.2.3.0/24)

Example using NATed IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
     (1.2.3.0/24) +-----> DMZ (10.99.0.0/24)

The advantage I see for using the NATed address is portability - I don't need to renumber my internal DMZ if my upstream provider and allocation changes. The downside is complexity - now I have to deal with inside vs. outside IP addresses within my own network, etc. In your experience, which setup works better?

The company I work for is going to be moving offices soon, and the new space is completely lacking in power or ethernet cabling right now. About 1/2 of the total office space is a 30'x30' open room, where the engineering team (about 10 people) will sit. Our prior layout was pods of 4 desks facing each other; we'll probably do something similar in this setup (I don't have the exact measurements yet to know how it'll all fit.)

Specifying power and drops for the remaining office space is easy - pick a spot on the wall. But I'm not sure what the best strategy is for a big open room. Slightly raised cable raceways with power and ethernet? Recessed floor jacks? Power poles running down from the ceiling? Also, does it make sense to home-run all the networking to a central wiring closet, or to simply run 1-2 connections for the entire room and use a good switch for all the systems in that room?

I have a setup where I'm routing hundreds to potentially thousands of SSL-enabled websites through a single virtual IP that does SSL offloading and load balancing. Thanks to the design of SSL itself, I need to have each "SSL host" listen on a unique port and/or IP address; in order to simplify the VIP setup, I'm simply assigning each certificate to a different port on the same VIP.

Externally, I want it to appear as if ports 80 and 443 are open on each IP. Internally, I want it so that each external port 80 maps to the internal host's port 80 (using standard HTTP virtual hosts to distinguish), whereas each port 443 maps to a specific internal port. So, for example:

External IP     External Port     Internal IP     Internal Port
1.2.3.1         80                10.0.0.5        80
1.2.3.1         443               10.0.0.5        20001
1.2.3.2         80                10.0.0.5        80
1.2.3.2         443               10.0.0.5        20002
1.2.3.3         80                10.0.0.5        80
1.2.3.3         443               10.0.0.5        20003

Implementing this with the ASA has been doable, but painful. Mapping each external IP address back to the same port requires the use of a unique ACL per external host, even if the ACL itself is identical. I've only been able to accomplish it with a combination of traditional static mappings and ACL-based static mappings, like so:

object-group service webapp_ports tcp
 port-object eq www
 port-object eq https
object-group network webapp_hosts
 network-object host 1.2.3.1
 network-object host 1.2.3.2
 network-object host 1.2.3.3
access-list policy_nat_http_site1 extended permit tcp host 10.0.0.5 eq www any 
access-list policy_nat_http_site2 extended permit tcp host 10.0.0.5 eq www any 
access-list policy_nat_http_site3 extended permit tcp host 10.0.0.5 eq www any 
access-list acl_outside extended permit tcp any object-group webapp_hosts object-group webapp_ports
static (inside,outside) tcp 1.2.3.1 www access-list policy_nat_http_site1 
static (inside,outside) tcp 1.2.3.2 www access-list policy_nat_http_site2 
static (inside,outside) tcp 1.2.3.3 www access-list policy_nat_http_site3 
static (inside,outside) tcp 1.2.3.1 https 10.0.0.5 20001 netmask 255.255.255.255
static (inside,outside) tcp 1.2.3.2 https 10.0.0.5 20002 netmask 255.255.255.255
static (inside,outside) tcp 1.2.3.3 https 10.0.0.5 20003 netmask 255.255.255.255
access-group acl_outside in interface outside

While this works, I'm unhappy with the setup because it requires far too much fiddling every time I need to add a new customer - adding the new IP to the object-group, a brand new access-list, and two more entries to the static mappings. Is there a better way to handle this? I'm in control of the entire network stack, so changes in the network design are also possible if that's the most appropriate thing to change.

I have an OpenDirectory server running on an OSX Server machine, and I'd like to increase the reliability of the service by having a slave server. The problem is, I only have 1 OSX Server but I have plenty of Linux servers available. I'm happy with Apple's tools that integrate with OpenDirectory, but given Apple's recent discontinuation of the XServe, I'm not particularly interested in continuing with Apple hardware.

I remember hearing that OpenDirectory is (now-distantly) based off the OpenLDAP code base; is there any way I could replicate from OpenDirectory to OpenLDAP instead of having to purchase another OSX server?

There are plenty of tutorials on setting up AnyConnect on an ASA unit, and a handful of links noting that IOS 12.4(15) and later support AnyConnect, but I can't seem to find any good documentation about how to setup AnyConnect on IOS; most tutorials assume you only want a clientless VPN on IOS. the best I've found is this document on Cisco's site, but it's not working for me in practice - see below.

This is all on a Cisco 881W:

router#show version | include Version
Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 12.4(20)T1, RELEASE SOFTWARE (fc3)
ROM: System Bootstrap, Version 12.4(15r)XZ2, RELEASE SOFTWARE (fc1)

The old SSL VPN Client seems to install just fine:

router#show webvpn install status svc  
SSLVPN Package SSL-VPN-Client version installed:
CISCO STC win2k+ 1.0.0 
1,1,4,176
Thu 08/16/2007 12:37:00.43 

However, when I install the AnyConnect client, after authenticating it hangs for a while during the self-update process, and stops with an error that the "AnyConnect package unavailable or corrupted."

When I try to install the AnyConnect package on the router, I'm told that it's an invalid archive:

router(config)#webvpn install svc flash:/webvpn/anyconnect-win-2.3.2016-k9.pkg
SSLVPN Package SSL-VPN-Client (seq:2): installed Error: Invalid Archive

Does anyone have a good sample on how to get the 2.x AnyConnect clients working with a Cisco device running IOS?

Most low-cost SSL certificate providers really only verify that you control a domain name. For those types of certificates, rather than pay a third party to verify that I control the DNS records for the domain, why not "sign" the certificate in DNS? If I generate a keypair on a server and publish the same public key in DNS for the hostname, I'd think that would be an equivalent level of security.

I see two problems with the design, but both seem minimal:

1. EA certificates and the higher-level certs that verify personal/corporate details can't be done this way. Organizations wishing to pay to get the green bar in browsers are free to continue doing so.
2. A malicious network with rogue DNS servers could redirect you to both a different hostname and a different trusted SSL certificate. Perhaps DNSSEC could take care of this repudiation problem?

I'm not aware of any browsers implementing something like this, but it seems like it would be a good method to at least get a trusted, encrypted connection without displaying the dreaded "Untrusted certificate" dialog. Aside from the issues I noted above and existing commercial certification authorities fighting the idea, are there any other reasons doing this would be a bad idea?

I have an Apache server that's proxying to Tomcat via mod_jk. I've set up a custom log in Apache to log the access times:

LogFormat "%h %l %u %t \"%r\" %>s %b %D" transfertimes
CustomLog /path/to/transfer-times.log transfertimes

I'm running ApacheBench on the web server itself. I've noticed that as I increase the concurrency, my 99th percentile request times appear to exponentially increase, although the 50th percentile remains relatively stable. As an example, ApacheBench will say that roughly 10 requests of 1000 take > 1 second to respond with a concurrency level of 100.

However, when I look at the transfer-times.log, no requests show up as greater than 1 second, based on the %D in the LogFormat. I'm trying to figure out what would cause the disparity between Apache's log and ApacheBench's reported access times. Normally I could attribute it to network latency, but I'm running this all on a single host. I'm thinking there must be something quirky with Linux TCP parameters or file descriptors I need to tune, but I'm not sure where to start.

Here in the USA, most consumer power strips seem to make use of NEMA 5-20R connectors - they look something like this. However, in the rackmount/datacenter world, I see a lot of power distribution units that accept IEC C14 connections instead, which look like this.

I know there's no significant difference electrically; I'm wondering why I should prefer one over the other. In my limited experience, I've found that connecting C14 connections to a PDU results in looser connections that I'm more likely to have fall out without securing them with zipties or velcro.