Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
I have a Netgear N600 Wireless Dual Band Gigabit Router (WNDR3700v3). "NAT Filtering" is set to "Secured" (as opposed to "Open"), and "Disable SIP ALG" is unchecked. It's my understanding ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2012
    Posts
    3

    Packets getting past my router?


    I have a Netgear N600 Wireless Dual Band Gigabit Router (WNDR3700v3). "NAT Filtering" is set to "Secured" (as opposed to "Open"), and "Disable SIP ALG" is unchecked. It's my understanding of the device that these are the correct settings for stateful packet inspection.

    Yet, I have packets showing up on my logs which make it look like the router is letting some packets though that it shouldn't, like this.

    Code:
    May 24 21:29:44 localhost kernel: [10721.310647] INVALID STATE: IN=p6p1 OUT= MAC={trimmed} SRC=69.171.229.70 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x20 TTL=243 ID=55272 DF PROTO=TCP SPT=80 DPT=42843 WINDOW=0 RES=0x00 ACK RST URGP=0
    I'm hoping someone can look at my firewall configuration (Fedora 16) and see if it's correct or if a misconfiguration is causing these packets to be logged.

    If it's configured correctly, is there some explanation for why this is happening other than a problem with the router?

    Code:
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    :PORTFWD - [0:0]
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "INVALID STATE: "
    -A INPUT -m conntrack --ctstate INVALID -j DROP
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -d 224.0.0.0/4 -p udp -j ACCEPT
    -A INPUT -m conntrack --ctstate NEW -m connlimit --connlimit-above 2 -j DROP
    -A INPUT -m conntrack --ctstate NEW -p tcp --sport 0:1023 -j DROP
    -A INPUT -m conntrack --ctstate NEW -p udp --sport 0:1023 -j DROP
    -A INPUT -m conntrack --ctstate NEW -j PORTFWD
    -A INPUT -j LOG --log-prefix "UNMATCHED: "
    COMMIT

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Looks like a web server you are/were connected to is the cause of this;

    From your log above
    Code:
    SPT=80 DPT=42843
    Since you started the connection it is allowed to pass the Netgear and your firewall. No breach that I can see here with what you provided.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined!
    Join Date
    May 2012
    Posts
    3
    Quote Originally Posted by Lazydog View Post
    Looks like a web server you are/were connected to is the cause of this;

    From your log above
    Code:
    SPT=80 DPT=42843
    Since you started the connection it is allowed to pass the Netgear and your firewall. No breach that I can see here with what you provided.
    So are you saying that the computer firewall was aware of the the connection's terminated status before the router, and that's why the router let it through but computer blocked it?

  4. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    What I am saying is the router has no way of knowing when the connection is closed and waits x amount of time to see if there is anymore traffic and if not then it too closes the connection.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  5. #5
    Linux Newbie nplusplus's Avatar
    Join Date
    Apr 2010
    Location
    Charlotte, NC, USA
    Posts
    106
    Quote Originally Posted by technojoe View Post
    I have a Netgear N600 Wireless Dual Band Gigabit Router (WNDR3700v3). "NAT Filtering" is set to "Secured" (as opposed to "Open"), and "Disable SIP ALG" is unchecked. It's my understanding of the device that these are the correct settings for stateful packet inspection.

    Yet, I have packets showing up on my logs which make it look like the router is letting some packets though that it shouldn't, like this.

    Code:
    May 24 21:29:44 localhost kernel: [10721.310647] INVALID STATE: IN=p6p1 OUT= MAC={trimmed} SRC=69.171.229.70 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x20 TTL=243 ID=55272 DF PROTO=TCP SPT=80 DPT=42843 WINDOW=0 RES=0x00 ACK RST URGP=0
    I'm hoping someone can look at my firewall configuration (Fedora 16) and see if it's correct or if a misconfiguration is causing these packets to be logged.

    If it's configured correctly, is there some explanation for why this is happening other than a problem with the router?

    Code:
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    :PORTFWD - [0:0]
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "INVALID STATE: "
    -A INPUT -m conntrack --ctstate INVALID -j DROP
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -d 224.0.0.0/4 -p udp -j ACCEPT
    -A INPUT -m conntrack --ctstate NEW -m connlimit --connlimit-above 2 -j DROP
    -A INPUT -m conntrack --ctstate NEW -p tcp --sport 0:1023 -j DROP
    -A INPUT -m conntrack --ctstate NEW -p udp --sport 0:1023 -j DROP
    -A INPUT -m conntrack --ctstate NEW -j PORTFWD
    -A INPUT -j LOG --log-prefix "UNMATCHED: "
    COMMIT
    I suspect the order of your "--ctstate INVALID" statements is what is getting you. I would expect any syn or synack packet to match an invalid state as it would not yet be in the state table. I can understand placing those statements before your "RELATED, ESTABLISHED" statement as a method of preventing some spoofed packet from sneaking into an ESTABLISHED flow, but if you intend to keep that rule ordering, I would expect you need to place all of your "NEW" matching rules before your "INVALID" matching rules.

    Are you able to pass any traffic with this ruleset?

    N

  6. #6
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Quote Originally Posted by nplusplus View Post
    I suspect the order of your "--ctstate INVALID" statements is what is getting you. I would expect any syn or synack packet to match an invalid state as it would not yet be in the state table. I can understand placing those statements before your "RELATED, ESTABLISHED" statement as a method of preventing some spoofed packet from sneaking into an ESTABLISHED flow, but if you intend to keep that rule ordering, I would expect you need to place all of your "NEW" matching rules before your "INVALID" matching rules.

    Are you able to pass any traffic with this ruleset?

    N
    I am going to have to disagree with you 100% on the rule order. The above rule order is correct and preferred.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  7. #7
    Linux Newbie
    Join Date
    Jan 2012
    Location
    Ohio
    Posts
    175
    Quote Originally Posted by Lazydog View Post
    What I am saying is the router has no way of knowing when the connection is closed and waits x amount of time to see if there is anymore traffic and if not then it too closes the connection.
    I am going to have to agree with Lazydog here. I don't think you have any configuration errors. The router will never now of a closed connection prior to the initiating client. That is why you run defense in depth by having the Stateful packet inspection on the router and a firewall on the client.

  8. #8
    Linux Newbie nplusplus's Avatar
    Join Date
    Apr 2010
    Location
    Charlotte, NC, USA
    Posts
    106
    Quote Originally Posted by Lazydog View Post
    I am going to have to disagree with you 100% on the rule order. The above rule order is correct and preferred.
    Hey, Dawg,

    Care to offer up a reference for my own enrichment regarding your assertion of "preferred?"

    And as far as your explanation of the logs to TechnoJoe, are you simply suggesting the router's session timeout is longer than the local firewall's?

    N

  9. #9
    Just Joined!
    Join Date
    May 2012
    Posts
    3
    Quote Originally Posted by nplusplus View Post
    Hey, Dawg,

    Care to offer up a reference for my own enrichment regarding your assertion of "preferred?"

    And as far as your explanation of the logs to TechnoJoe, are you simply suggesting the router's session timeout is longer than the local firewall's?

    N
    The rule to drop INVALID packets is there to remove from the chain as soon as possible packets that the system already knows are bad. Not every firewall configuration is as simple as mine. A complex configuration, especially a blocklist, could easily reach 200 rules. Then you'd have known bad packets traversing 200 rules just to fall off into the default DROP. Removing them immediately saves system load.

    As to my original question, I would have thought that the RST packet sent by my computer to signal the close of the connection would be picked up by the router. Or are you saying that a few packets might sneak through in the small window after the computer updates the session but before the router does?

  10. #10
    Linux Newbie nplusplus's Avatar
    Join Date
    Apr 2010
    Location
    Charlotte, NC, USA
    Posts
    106
    Thanks, Joe. Makes sense. I wasn't thinking it through completely on my first reply. Of course, the iptables man page is a little unclear as to what constitutes an INVALID packet. I would expect it to pass SYN, and SYN-ACKs (neither of which matches the log entry you provided anyway), but for ctstate, the man page indicates it means "the packet is associated with no known connection," which to me, would also mean "NEW."

    For "state," the man page is a little more inclusive re: the meaning of INVALID, though neither refers to what I would normally consider INVALID (i.e. all flags set, no flags set, non-RFC compliant, etc.).

    N

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •