Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    L7 not functional

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    7 Posts 4 Posters 4.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      carpa
      last edited by

      Hello pfSense community :)

      there is something weired going on with the L7 functionality.
      I've tried for hours to get it working, without success - the problems are (running version:  pfSense-2.0-ALPHA-ALPHA-2g-20091205-2144-nanobsd-upgrade) :

      only one pattern out of the 5 i've tried got detected at pattern matching : shoutcast

      L7 - Container voice:
      -ventrillo
      -skyetoskype
      -teamspeak
      -shoutcast

      L7 - Container ftp:
      -ftp

      In my tests, i only activated one L7-container at once. When activating the voice container, just shoutcast is recognized as found-pattern while running shoutcast  - the other protocols aren't getting caught.
      Even the standalone ftp container isn't working. This seems a bit strange to me, since the FTP pattern is marked to be best quality at http://l7-filter.sourceforge.net/protocols.
      I rebooted pfsense after each change, just to be sure.
      The ipfw-classifyd loads at the system logs are okay, e.g. for my ftp container : ipfw-classifyd: Loaded Protocol: ftp (rule action block)
      But i only get "Found Protocol" for shoutcast :
      ipfw-classifyd: Found Protocol: shoutcast (…)  -> refering to scenario1 shown in 2)

      enabling these L7 filters at Firewall -> Rules -> LAN
      (i followed the instructions from http://roadtoqos.wordpress.com/) …. as shown in the screenshots i used as source adress my home pc , but i've also tried with source : any

      my WAN / LAN settings are :

      scenario1:
      when setting up the L7 filter (shown as deactivated LAN-rule : L7 Voice and Stream) as first rule - some strange things happen:

      -after establishing ANY connection with ANY protocol, after about 20-30s the connection gets lost to my home Pc (shown as myPC in the settings)
      -the pattern detection for shoutcast is here working (the others still don't) only for queues, block doesn't work even for this one … when trying to block shoutcast, the system log shows : ipfw-classifyd: Found Protocol: shoutcast (rule action block) - but no block occurs

      example firewall Logs for connection drops

      http

      shoutcast

      scenario2:
      when setting up the L7 filter (shown as deactivated LAN-rule : L7 Voice and Stream) as last rule just before block everything :
      -not even the L7 Shoutcast filter works (neither block nor putting it to a specified queue)
      -no connection drops

      did i something wrong or is there a bug in the L7 system ?

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        Please post your /tmp/rules.debug and a ps -ax command output.

        It would be good if i can have you config.xml to see if anything is wrong too.

        1 Reply Last reply Reply Quote 0
        • C
          carpa
          last edited by

          you've got a pm with the files

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            Please try the latest snapshot.

            1 Reply Last reply Reply Quote 0
            • C
              carpa
              last edited by

              with the actual snapshot 12/12/09 L7 is still broken.
              at first i've installed the "update" version , then a full install with a brand new config - no change at all

              so still :
              -after enabling a random L7 rule (eg. FTP or shoutcast, doesn't matter which one) : the firewall drops now every connection to the WAN after a few seconds as shown in my first post regardless of the protocol used.
              -assigning a L7 rule to block , doesn't block the specified L7-protocol

              new since this version :

              I created 4 L7 container, each of them containing only one L7 pattern assigned to a queue (with or without assigning the containers as firewall rule, doesn't matter):

              Systemlog:

              ipfw-classifyd: could not get ALTQ translation for queue qOthersHigh
              ipfw-classifyd: could not get ALTQ translation for queue qOthersHigh
              ipfw-classifyd: could not get ALTQ translation for queue qOthersDefault
              ipfw-classifyd: could not get ALTQ translation for queue qOthersHigh

              ps:
              -a bug i've seen during install : http://incubi.cwsurf.de/files/pfsense/bug.txt
              -since the new version : i can't log in with ssh using my ssh-rsa key -> it is being rejected … password login still works (privileges : WebCfg - All pages, User - System - Shell account access)

              1 Reply Last reply Reply Quote 0
              • C
                carpa
                last edited by

                update :

                running version pfSense-2.0-ALPHA-2g-20091213-1725-nanobsd-upgrade now

                just tested again, and can now give more specific details about the L7-block issue :

                -blocking a L7 protocol works, until the firewall blocks a not by the L7 matched traffic (which it shouldn't , like established http traffic as shown in the first post)
                -when this happens, one can establish a connection with the blocked L7 protocol.

                1 Reply Last reply Reply Quote 0
                • T
                  ttlinna
                  last edited by

                  @carpa:

                  update :

                  running version pfSense-2.0-ALPHA-2g-20091213-1725-nanobsd-upgrade now

                  just tested again, and can now give more specific details about the L7-block issue :

                  -blocking a L7 protocol works, until the firewall blocks a not by the L7 matched traffic (which it shouldn't , like established http traffic as shown in the first post)
                  -when this happens, one can establish a connection with the blocked L7 protocol.

                  I've stumbled with this same issue also for a long time. Is this problem already fixed?

                  BR,

                  Tommi

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.