Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 9993 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Default Drop Issue

DaMaN841
Hi Folks,

Noticed some traffic that was being blocked and I'm trying to determine what obvious rule I'm missing.

Default DROP: TCP  
146.148.44.137: 56700 
  • Internet IPv4 --> 56700→1:65535 --> Internal Host (that I expect it to go to)
  • Internet IPv4 --> Any --> Internal Host (that I expect it to go to)
  • Internet IPv4 --> 56700→1:65535 --> External WAN (Address)
  • Internet IPv4 --> Any --> External WAN (Address)
[/LIST]
The TCP packet that is dropped is the WAN IP, which is why I added the last two rules, however, it confuses me to swap out Internal Host with External WAN. Reading it seems circular since Internet IPv4 is External WAN (Network); External WAN (Network) --> 56700→1:65535 --> External WAN (Address). Seems strange to me.

With that in mind, I then considered using 146.148.44.137 --> 56700→1:65535 --> External WAN (Address), however, I'd prefer not to lock it down to that IP.

Any clarification from an abstract perspective would really help. I haven't had to deal with this direction before, less port forwarding. I even looked at Automatic Rules, however, nothing really mirrored what it seems like I'm attempting [:S]

Cheers,
Kyle


This thread was automatically locked due to age.
  • 0
    I continued tinkering to model Port Forwarding Rules and so I appended the following rules:
    [LIST=1]
    • Any IPv4 --> 56700→1:65535 --> External WAN (Address)
    • Any IPv4 --> Any --> External WAN (Address)
    [/LIST]
    This seems to make the most sense. I hope I'm on the right track.

    Cheers,
    Kyle
  • 0
    Kyle, when posting a line from the firewall log, use the line from the full Firewall log file.  Unlike the other Live Logs, the Firewall Live Log omits the details needed to analyze a problem.

    I bet when we look at that, you will see that you don't need any of those rules and that you don't have a problem.  Certainly, if these are all RST packets and you haven't noticed interrupted downloads, then you can ignore the blocks.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob,

    Understood. I used the Search Log Files capability to easily track it down originally, however, I was able to find it in the actual log once I knew what to grep.

    2015:06:07-21:24:22 tornado-1 ulogd[5791]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="64:00:f1:7b:e9[:D]a" dstmac="00:1a:8c:f0:e1:a0" srcip="146.148.44.137" dstip="WAN IP" proto="6" length="40" tos="0x00" prec="0x00" ttl="45" srcport="56700" dstport="55955" tcpflags="RST" 

    2015:06:07-21:43:47 tornado-1 ulogd[5791]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="64:00:f1:7b:e9[:D]a" dstmac="00:1a:8c:f0:e1:a0" srcip="146.148.44.137" dstip="WAN IP" proto="6" length="40" tos="0x00" prec="0x00" ttl="45" srcport="56700" dstport="56000" tcpflags="RST" 

    2015:06:07-20:57:36 tornado-1 ulogd[5791]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="64:00:f1:7b:e9[:D]a" dstmac="00:1a:8c:f0:e1:a0" srcip="146.148.44.137" dstip="WAN IP" proto="6" length="40" tos="0x00" prec="0x00" ttl="45" srcport="56700" dstport="55798" tcpflags="RST" 



    I am having issues with this particular service, which is why I went hunting in the first place. Whether or not these contribute to the problem is what I'm hoping to determine.
  • 0
    If you're not getting disconnected unexpectedly, Kyle, then this is normal.  The server at 146.148.44.137 didn't realize that the conversation was over and is saying "hey, are you still listening?"  The connection tracker in your stateful firewall has finished the conversation and no longer knows what internal IP it would send that traffic to.  In fact, it's almost certain that the internal client wouldn't know what to do with the packet if it got to him.

    I just read the last line of your post.  I'll be back in a minute to edit this.

    Cheers - Bob
  • 0
    Did you create a NAT rule first to allow the external IPV4 traffic into the (presumably) private range internally?
  • 0 in reply to darrellr_01
    That makes sense, Bob. Thank you.

    I have not, darrellr. The only thing that they claim is required is opening TCP 56700. I see plenty of traffic under Network Usage (outbound).

    I'm really not convinced that the Firewall Configuration is the problem, however, I noticed the drops so I thought I'd bring it to the attention of the community to rule it out. Based on what Bob pointed out, I have a feeling that it is on their end...perhaps closing the conversation too early or not early enough. It certainly seems to be a LIFX Cloud problem. 

    I'll be contacting LIFX to determine if they can determine what's going on. Thanks guys!

    Cheers,
    Kyle
  • 0
    Kyle, I got busy and didn't make it back.  Can you let us know more about what kind of issue you're having with LIFX?  There are some timeouts that could be lengthened depending on how the problem presents itself.

    Cheers - Bob
  • 0 in reply to BAlfson
    Bob,

    I was actually going to respond this afternoon, however, I became preoccupied with work until your email notification came in.

    I contacted LIFX yesterday afternoon, actually, and they told me they were providing a firmware update that addresses the connection dropouts. Very impressive customer service, I might add.

    As it turns out, I was able to acquire the firmware update last night and everything has been working without a hiccup. The nerd that I am, my entire house now flashes blue when the AC turns on, flashes red when the Heat turns on (both of which return to the previous setting), turn on when I arrive at home and turn off when I leave home. 

    Now that it's stable, I'll be creating more obnoxious recipes [:D]

    I'm going to continue to monitor the logs to see if with their fix if it happened to address the dropped packets from their end.

    Thanks so much for your assistance, I really appreciate it!

    Cheers,
    Kyle