Mike, thanks for getting back to me so quickly.
>      I know that the --HTTP option in fwknop encapsulates a SPA in an 
> HTTP request. At the moment, however, I can't come up with a good way to 
> get that request to go through the proxy.

I suspect that the fwknop client is not able to create a "sufficiently
valid" HTTP request according to what the proxy requires.  For example,
fwknop does not ensure that the SPA packet data starts with "/", and it
also does not append, say, ".html" at the end 
Actually, the main problem is that the proxy is not intercepting all http requests. To get a http request to the internet, we have to explicitly send that request to the proxy.  This packet has to include the FQDN in the request. In essence, we have to use wget to send
"Get HTTP://mydomain.com/BigLongFwknopKey" to the proxy. 
My server sees "GET /BigLongFwknopKey  HTTP/1.1" 404 461 "-" "Wget/1.10.2"

I've compared the httpd logs from a valid SPA with the log entry of our SPA going through the proxy. The two differences that I see is the leading "/" and the "Wget/1.10.2" rather that "fwknop" at the end of the packet.My suspicion is that the leading "/" is throwing off the SPA detection.
(although hopefully the
proxy doesn't actually require the later since lots of web traffic
doesn't necessarily conform to this).
It does *not* require a ".html". It *does* require the FQDN "http://mydomain.com"
  Also, if you are using GnuPG,
then the resulting SPA packet data is most likely about 1,000 bytes long,
so this may look suspicious to the proxy.  Do you know what rules the
proxy enforces?

It seems to allow any http request that has the full domain name. No UDP of any sort can get through, though. There is also NTLM Authentication required. Wget's proxy username-password options do work.
You can monitor the requests the make it to your home webserver,
correct?  Can you try the following to see if the SPA data makes it
through the proxy?:

- Use the fwknop client to build an SPA packet, and use the "-v" option
  so that the SPA packet data will be printed on stdout.
- Take the SPA packet data and use wget on the command line to manually
  build an HTTP request with this data.  However, add "/" to the
  beginning of the data, and append ".html" to the end.
- You can try this with both Rijndael and GnuPG, but I would try with
  Rijndael first (just don't use any --gpg options).

A "wget http://example.com/FwknopKey" does not get through.
With the proxy setting configured correctly in wget, that line does get through, but doesn't trigger the port to open. In my situation, the ".html" is not needed, but it wouldn't be a problem to be there.

Please note that -v works with the new fwknop-c client too.

If the above results in any of your SPA packets getting through the
proxy as a valid HTTP request, then I will add support for this to the
fwknop client (and the server will require a small modification too).

I'm going to suggest that you add support for a "--proxy" option for the HTTP requests. It should send the request to the proxy address and port. Having authentication for a proxy that needs it would be nice, but if fwknopd would ignore that leading "/", we could use wget.
Oh, one more thing, the fwknop-1.9.12-pre6 release did include one small
change to build HTTP requests with SPA data such that the request uses
the pre-DNS resolution hostname instead of the IP (if you provided a
hostname with -D on the fwknop command line).  This change was made to
allow webservers to see the hostname so they can apply things like
virtual hosting configs, etc.

This is perfect, as some proxies balk at a request for an ip. They want the domain name. (the one we are fighting, especially)


I really appreciate the help,
Jonathan Bennett