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

    Yet another "cant make the rule working"

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 2 Posters 648 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.
    • G
      gratis.obake
      last edited by

      greetings to all,

      I'm a pfsense newbie and I get a few tons problems with pfsense but I'll try to tackle each problem one by one.

      problem 1 of many:

      I have 6 computers at home, 1 acting as an iscsi server for the 5 other computers.
      these 5 computers are diskless and therefor sending/receiving huge amount of traffic on the LAN.
      server ip is: 192.168.1.222 (seen as lilserver in tcpview)
      client ip range is: 192.168.1.10x (seen as unit106.localdomain in tcpview)
      port used in the server for the iscsi is: 3260 (see tcpview screenshot)

      I have created something like this (please see screenshot attached)
      -LAN
      –qLink
      ---qCCBoot

      qLink have 990Mb bandwidth
      qCCBoot have 100% bandwidth

      and then created firewall rules in either floating or on LAN and direct them to qCCBoot queue (see screenshot attached)
      I did reset the firewall state table just to make sure also and reload the rules, but when I try to see the queue from GUI or console, it is still not going to the qCCBoot queue.

      I did try to run TCPView from windows and I do see it is using port 3260 from the server.

      what I'm trying to achieve is to move the iscsi (or whatever this diskless traffic is) away from qDefault queue.

      any help is appreciated. thanks in advance
      pfsense.jpg
      pfsense.jpg_thumb
      tcpview.jpg
      tcpview.jpg_thumb
      pfsense2.jpg
      pfsense2.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        server ip is: 192.168.1.222
        client ip range is: 192.168.1.10x
        port used in the server for the iscsi is: 3260 (see tcpview screenshot)

        If your iSCSI server and your clients are on the same subnet, pfSense isn't involved at all.  Look at your switch for DSCP or other QoS.  And don't overthink it.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • G
          gratis.obake
          last edited by

          thank you sir for your reply but I am at lost here :(

          I am assuming that what qDefault is also getting the packets from the iscsi communications between the server and the client, although it is indeed on the same subnet.

          edit–-
          my main concern is that qDefault is too much saturated on which I'm not doing anything at all for the connections.

          I don't know either how to view this specific packet that is running inside qDefault also :(

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Traffic from one host on the local network to another host on the local network doesn't go through pfSense at all.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • G
              gratis.obake
              last edited by

              ok sir, I'll do take note of that, thanks for the explanation.

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