• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Dec 9, 2009, 3:03 PM Dec 9, 2009, 2:56 PM

    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 Dec 9, 2009, 3:07 PM

      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 Dec 9, 2009, 3:36 PM

        you've got a pm with the files

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by Dec 12, 2009, 5:09 AM

          Please try the latest snapshot.

          1 Reply Last reply Reply Quote 0
          • C
            carpa
            last edited by Dec 13, 2009, 2:20 PM Dec 13, 2009, 2:07 AM

            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 Dec 14, 2009, 5:57 PM Dec 14, 2009, 5:54 PM

              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 Jan 6, 2010, 8:50 PM

                @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.
                  This community forum collects and processes your personal information.
                  consent.not_received