Thread Info
  • State Not Answered
  • Replies 13 replies
  • Subscribers 0 subscribers
  • Views 3929 views
  • Users 0 members are here
Options
Suggested

[8.900][CLOSED] Web Protection error if tunnel broker is down

UrsWeiss
As i have described in another post, my tunnel broker (Freenet6) stays down after an UTM9 reboot. This evening i had to reboot it again because of a strange DHCP error i have not debugged yet. I forgot to restart the tunnel broker manually after reboot, and that brought me to another problem if that happens.

Later this evening i wanted to access a IPv6 enabled website (streams.xenim.de) and the UTM showed me the error "Address family not supported by protocol" (s. attached screen shot).

Log entry: 
2012:03:08-23:09:44 whity httpproxy[4378]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="2001:5c0:x:x:x:x:x:e58e" dstip="79.140.41.30" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="2675" request="0x10a94cd0" url="static.streams.xenim.de/.../Business Forums"


Then i recognized that the tunnel broker is not connected anymore (because of the reboot earlier). It was still enabled, but not connected. After restarting it, the site worked again.

So i tried to find the real reason why this occurs. And i think it's because of the DNS cache. IPv6 access to the Internet doesn't work anymore, but the DNS cache of the UTM still has the IPv6 address in his cache and returns it to the client, which then tries to access to the IPv6 address which fails.

Disabling the tunnel broker if the IPv6 enabled site is in the DNS cache has the same effect btw.

Don't know what would be the best way to prevent this behavior.
  • 0
    Bind will empty its cache on restart of the daemon or reboot of the UTM. Also enabling a tunnel broker just lets you create a tunnel to the ipv6 enabled websites. Your system is already ipv6 capable so your dns queries for example would resolve an ipv6 address if queried no matter if you are connected to the tunnel broker or not.

    For example you can try 
    dig AAAA nscache.us.sixxs.net
     even if you are not using ipv6 and you will get something like  
    ;; ANSWER SECTION:

    nscache.us.sixxs.net.   3600    IN      AAAA    2001:4de0:1000:a3::2

    nscache.us.sixxs.net.   3600    IN      AAAA    2001:4de0:1000:a4::2


    So DNS is not the error, the tunnel broker is. With that out of the way, I am not really sure how would you like the proxy to handle the error situation when it has no route to the host.

    Regards
    Bill
  • 0
    You're right, AAAA records can be resolved even if you are on IPv4 only of course.

    I am not really sure how would you like the proxy to handle the error situation when it has no route to the host.


    That's the question...

    Should it be handled somehow (if possible) or not? Do we have to live with it?
    I mean, all this tunnel broker stuff isn't made for production use anyway in my eyes.

    If you have an IPv6 enabled network but no way out over IPv6, you will get more and more problems over time.

    My thoughts where:
    - Is there may a way back to tell the client: "sorry no IPv6 available, try IPv4"
    - The proxy is able to access the requested site over IPv4 itself if IPv6 is not available

    (Just some ideas...)
  • 0
    Hi Whity,

    what exactly did you have configured when the Web Filtering reported the "Address family not supported by protocol" error? Can you still reproduce the issue in this configuration?

    Regards,
    mlenk
  • 0
    You mean the configuration of the Web Protection?
    Reproduce with which configuration?

    The problem is that, as soon there is no internet connection over IPv6 (because tunnel broker is down), you will get this error on a client with IPv6 enabled.

    I think the only solution would be to make the UTM act as a IPv6 / IPv4 gateway.
  • 0
    Whity, I will try to reproduce your problem later today.
    Are you using the proxy in standard or transparent mode? Is your client only using IPv6 or IPv4+IPv6?

    Edit: I just tried to reproduce this by using the proxy in transparent mode, and using a dual homed client. When I enabled the Freenet6 tunnel, the proxy used IPv6 to access streams.xenim.de, and when I disabled the Freenet6 tunnel in webadmin again the proxy used IPv4 for streams.xenim.de again.
  • 0
    Hi ulmi, I don't think the problem is there if you gracefully turn off the tunnel. In whity's case the tunnel broker is failing on a reboot and at that time the proxy is still sending traffic to ipv6 address instead of failing over to ipv4. 
    Regards
    Bill
  • 0 in reply to Billybob
    Hi,
    I received that address error and thought it was the sites I was surfing to. As far as I know my IPv6 tunnel (freenet6) was up.
    The urls were very long, over many lines in the error report.

    I have not been able to replicate the failure, but will search the logs tonight to locate the error message.

    Not sure what mode the proxy was in because I was experimenting with settings and searching for proxy pac information.


    Ian
  • 0
    If i have some time tonight i will try some more things.

    The tunnel broker failed, but i was able to reproduce it by disabling the tunnel broker back then. Will also try that again.

    I use a MacBook Pro with IPv6+IPv4, Proxy in transparent mode, Virus scanning enabled, nothing blocked in URL Filtering.
  • 0 in reply to UrsWeiss
    Hi Whity,
    a similar setup except I have DNS, NTP and some MS protocols blocked in network security. The error only occurred on some sites.

    2012:03:11-03:30:03 *** httpproxy[6427]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xc5b8a2d8" function="connect_server" file="dns.c" line="957" message="bind: Address family not supported by protocol"

    Now to check the IPv6 log. No entries in the log for that day.

    Ian
  • 0
    The UTM acts as DNS for all clients in my setup...

    It can only happen if the URL you try to access is reachable over IPv4 AND IPv6 (has A and AAAA records in DNS). If it's IPv4 only, it works anyway, if it's IPv6 only you'll get a "Host not found"
Cookie Information Banner