Mike, thanks for getting back to me so quickly.
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
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
"Get HTTP://mydomain.com/BigLongFwknopKey" to the proxy.
My server sees "GET /BigLongFwknopKey HTTP/1.1" 404 461 "-"
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
It does *not* require a ".html". It *does* require the FQDN
(although hopefully the
proxy doesn't actually require the later since lots of web traffic
doesn't necessarily conform to this).
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.
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
A "wget http://example.com/FwknopKey" does not get through.
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).
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.
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.
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).
This is perfect, as some proxies balk at a request for an ip. They want
the domain name. (the one we are fighting, especially)
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.
I really appreciate the help,