Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 9994 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.
Parents
  • 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
Reply
  • 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
Children
  • 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.