Incoming packets

Discussion in 'LnS English Forum' started by Aerowinder, Nov 14, 2007.

Thread Status:
Not open for further replies.
  1. Aerowinder

    Aerowinder Registered Member

    Joined:
    Aug 15, 2007
    Posts:
    29
    Below is a rule I created to play Company of Heroes (by Relic Entertainment) online. This rule works fine, but I have a question.

    http://img.photobucket.com/albums/v407/Aerowinder/rule.jpg
    rule.jpg

    I guess I need a little clarification on client/server relationships. In the illustration above, my local UDP port 6112 is open to the specified IP:port range. If I removed port 6112 from the Source side, the Destination would still be able to connect to me. Putting 6112 in that field just states that port 6112 is the only port those addresses can connect to on my system. Port 6112 has to be open to receive the incoming data either way. So either way, I am acting effectively acting as a server to my destination. Right?




    Below is a rule for Azureus, a BitTorrent client.
    http://img.photobucket.com/albums/v407/Aerowinder/rule3.jpg
    rule3.jpg

    This opens UDP port 21377 (while the program is running) to the outside world. I am acting as a server here. I am sending data to anyone who requests it.




    Below is a rule for Ventrilo 3.0, to allow it to get past it's "Synchronizing" stage.

    http://img.photobucket.com/albums/v407/Aerowinder/rule2.jpg
    rule2.jpg

    The IP addresses vary, and so do the destination ports. So I can't restrict it much farther. This means any application I have approved can send data to anywhere on UDP port 6100.




    After telling you all this, my real question is: should I leave the left fields (Source) blank, if possible? Or does it not even make a difference? Is it the Direction field that decides if I can act as a server? Does this post even make sense? I thought the pictures would help me explain.

    Does choosing the "Inbound/Outbound" direction make me a server by default? If that's the case, I should make the Source/Destination as restrictive as possible.
     
    Last edited by a moderator: Nov 14, 2007
  2. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Yes, this is correct, this is the intention of such a rule.
    However for UDP protocol there is no real connection, so the rule could correspond also to your PC acting as a client and sending a packet to a port within 30260-30270 as the destination port, and 6112 as source port.
    Yes, correct.
    If the destination ports are changing for each connection, yes you have to leave the left fields blank.
    When the ports are fixed, of course it is better to specify them to allow only the expected packets.
    No, the direction field will not help here. This field just indicate if the rule applies to incoming packets, outgoing packets, or both kind of packet.

    The next update will introduce an additional SPI (Stateful Packet Inspection) engine, and it will be possible to do what you are looking for (if I've understood properly). With this SPI it will be possible to:
    - block incoming packets if a first packet has not been sent first on a particular port (as a client)
    - block outgoing packets if a first packet has not been received first on a particular port (as a server)

    Regards,

    Frederic
     
  3. Aerowinder

    Aerowinder Registered Member

    Joined:
    Aug 15, 2007
    Posts:
    29
    Thanks for the response.


    So for clarification; right now, with this rule:
    [​IMG]

    This will allow any system to send a UDP packet to me, if it originates from port 6100 on the remote PC? I was under the impression LnS automatically blocks outgoing UDP. I had to make that rule so I could send data to a remote PC on port 6100, and in turn, it could send data back to me.

    This is what the SPI update is going to address? I think this post better addresses my concerns than the last.
     
  4. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,726
    Location:
    Canada
    Hi Aerowinder,

    The Rule-based SPI will offer you means to make stateful-like rules for connectionless protocols like UDP...
     
  5. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi Aerowinder,
    Yes, if your PC receives a packet with the source port set to 6100, the packet filter will accept it.
    Yes, by default if there is no rule added on top of the standard rulesets, any UDP traffic is blocked. If you need to send data on port 6100 and receive packets from the remote, then you need this rule, and it allows incoming packets with a source port set to 6100.

    Yes, it address more than your case, because it applies to other protocols like ARP, ICMP, and it address the application level too (DNS, DHCP...) for simple protocols.
    In your case, as long as your PC doesn't send a packet on port 6100, all incoming traffic with source port set to 6100 is blocked. Then your PC sends a first packet sent to destination port 6100 (and the packet includes a another source port and the destination IP address too), then the SPI detects it and will accept incoming packets with a source port of 6100, and only coming from the same remote IP as the first packet and only using the same source port (which is destination for received packet). If some other packets are coming from another remote machine with a source port set to 6100, or from the same remote machine but with another port, they will be still blocked.

    Frederic
     
  6. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Nice move Frederic. I look forward to that release.

    Regards,
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.