[5.015] HTTP Pages do not work with Surfprotection

Even WebPages on hosts only reachable over a VPN cannot be displayed. I mean things like webmin an co. even a local apache cannot be reached. Put the adress in the whitelist but that doesn´t work for me.

Only if I disable the proxy COMPLETLY it works .....

What can I do?
Alex

Hi there, 

it is not a proxy issue that websites through vpn tunnel do not work, 
but the VPN configuration you have.

I assume you have a site to site vpn tunnel and the HTTP proxy sits on the same machine as the tunnel end point.

If that is the case than the proxy itself is not part of the protected network.
Only your local network with which is behind the firewall can reach the other side.

Try to ping from the firewall another host in the remote network.
You will not reach him, because the firewall uses its default gateway interface to send the ping request, but this interface is not part of your protected network.
If you wish to do so, just create a second host to net tunnel, that your firewall is also allowed to access the remote network (same configuration as the net-to-net but without the local network).

I am still investigating the other problems.

Regards
Gert

Hi Gert,

it is a net to net VPN tunnel. I can reach the remote Apache only if the proxy on my ASL is disabled. Why doesn ´t that work with proxy? Is there a chance to make it work without disabling the proxy. I administrate the remote network so I have to reach it. But i cannot disable the proxy due to my other users....

Alex

Hi alasc, 

the problem is, that if your http proxy tries to access the other side of the vpn tunnel, he can't, as he sends his requests from the external interface, which is not allowed.

There are two ways of fixing this, 
a) create a host to net tunnel, so the firewall is able to reach the remote LAN.
b) create an SNAT rule, that rewrites the SRC IP of the request to the internal ip.
this on is not nice, but it should work.

the rule needs to look like this:
SRC: External IP
Service: HTTP
DST: remote LAN
change SRC to: Internal IP.

regards
Gert

Hi Sven, 

i also would like to take the opportunity to track down your problems, as nearly all others just work fine.

My home asl is Version 5.016.
I configured to HTTP-Proxy in Standard Mode with one Profile.

My Profile looks like this: 
- 5 Whitelist entries
- 5 Blacklist entries
- the surf protection category 'Nudity' is blocked
- Embedded Object Removal is OFF
- JavaScript Removal is OFF
- Virus protection for Web is ON

This profile gets assigned to all users from the 'Internal (Network)'.

I will test all URLs listed here if they work in my setup I will use the Internet Explorer Browser, as it seems that Mozilla/Firefox are far more compatible..

1. http://www.kreis-anzeiger.de/
the site itself works fine, but the search takes a lot more than 60 sec to complete,
the proxy takes this as a stale connection as it is dynamically generated and there is no content for a long period of time.
So this is the wanted behavior. we need this feature as this prevents the proxy from being unusable if many of those connections are established.
This means if you request a URL, and the content of that page gets dynamically generated AND if that takes more than 30 seconds, than the proxy thinks this is stale connection, and throws the error message.
You can either add this domain into the 'Whitelist Domains' or increase the timeout value of 30 sec.

2. http://ec.ingrammicro.de/obs/ec_index.htm
I  surfed to that site, but it seems that there is no java applet anymore.

3. http://www.heise.de/newsticker/
Works fine for me even with 30 times back and forth

4. http://www.motor-talk.de/
Works fine for me, surfed for 10 minutes without a problem.

5. http://www.banditforum.de/
this site is part of a bug or better missbehavior of encoding-type we found two days ago.
Explanation below.

6. http://www.castlerock.com/
this site is also part of the encoding-type problem.

7. http://www.seb.de/
surfing the site works fine, i also tried to login to the online banking with pin/tan,
i didn't came far, is have no account there [;)]
nevertheless, so far it worked. I also find out that they heavily use JavaScript for their validation of input.
Sven, do you block JavaScript?


Well so far all seems to work fine, except the Encoding type bug.
We are currently working on an improved version of the HTTP-Proxy.
This version will include the fix to workarounf the encoding-type problems.

We plan to release this new version end of August.

so plz stay tuned.

thx and regards
Gert





Encoding-Type Bug
-----------------

The problem lies within the http-request, our HTTP-Proxy sends out to the internet.

According to RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616.html), the HTTP-Proxy sets the HTTP-Request header field:
Accept-encoding: identity

This should tell the server the he must send the content in plain-text encoding, no deflate, gzip or other compression mechanism should be used.
We need this, because we can not to regular expression matching on compressed content
and so far we are not able to decompress the content.

But several servers (or their configuration) on the internet can not really cope with this flag correctly.

The RFC states that if the server can not serve this content type, he should send an error 406 (request not acceptable).
but instead of that, the server closes the connection with status 200 (all ok), but without sending the actuall page.

So it looks that this is a problem on the server side, which we need to workaround.

After talking to R&D, we agreed that we will remove this header field from the HTTP-Requests in the future, as in most of the cases, the servers default encoding type will be identity (plain text).

But if the server than sends a gzip/deflate/compress encoded content, we will block this response with an error message (unsupported content encoding).
We would see this in the logfile, and the administrator will be able to bypass this with the global whitelist. 

Workaround:
Add the domain name of the misconfigured server to "Whitelist Domains", this will workaround this issue.

I also have big issues with the content filter (ASL 5.017).
Configuration: 1 Profile (default) no entrys in black or whitlist (just to see wether my lists are wrong) embeded object and script removal disabled, VP on. No Category block. 
Profile Assignment: Default -> user ::none:: network: Any,
HTTP Proxy in Standard mode.
As soon as I enable the content filter i get wired behaviers of all browsers (IE, Mozilla, all fully patched) with different OS (2000, XP, latest patches.. XP with SP2)

Some examples:

side completly not loadable (empty browser window)
http:://www.hardwareluxx.de

pictuers in every article missing:
http://heise.de

back button not working (it seems it transfers just a part of the HTML code), I also saw this "feature" on other sides.
http:://innovatek.de/forum

and many other sides with sporadic problems like:
http://www.expedia.com http:://www.orbitz.com

When I put e.g. 
espn\.go\.com

into my blacklist i still see sides like "sports.espn.go.com" in my statistics from some users. When I try this page i get the correct block message from ASL.


As soon as I turn off content filter everything works fine.

Any suggestions on this?