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

    Trouble interpreting firewall log

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    4 Posts 3 Posters 2.2k 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.
    • J Offline
      jevo
      last edited by

      Hello,

      I'm having trouble interpreting a firewall log entry that comes through every few seconds.  My voip provider apparently generates frequent traffic to their sip adapter which sits behind my pfsense firewall.

      Here is a sample of the recurring entries.

      
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: 00:00:04.446925 rule 1/0(match): block in on pppoe0: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 264)
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf:     67.228.77.18.5060 > 75.45.179.75.24480: SIP, length: 236
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: <009>OPTIONS sip:75.45.179.75 (adsl-75-45-179-75.dsl.sfldmi.sbcglobal.net) :24480 SIP/2.0
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: <009>Via: SIP/2.0/UDP 67.228.77.18 (sip-byod.voipwelcome.com) :5060;branch=0
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: <009>From: sip:ping@voipo.com;tag=15e60be
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: <009>To: sip:75.45.179.75 (adsl-75-45-179-75.dsl.sfldmi.sbcglobal.net) :24480
      2011-03-09 10:52:30	Local0.Info	192.168.123.1	Mar  9 10:52:30 pf: <009>Call-ID: 9cfc\0x8c\0x9ewM\0xbdn\0x03\0x00\0x00\0x01\0x00\0x00I\0x01\0x00\0x00\0x14\0x00\0x00\0x00=\0x02\0x01\0x00pppoe0\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x01\0xff\0xff\0xff\0xff\0xff\0xff\0xff\0xff\0xa0\0x86\0x01\0x00
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: 00:00:07.992126 rule 1/0(match): block in on pppoe0: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 264)
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf:     67.228.77.18.5060 > 75.45.179.75.55852: SIP, length: 236
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: <009>OPTIONS sip:75.45.179.75 (adsl-75-45-179-75.dsl.sfldmi.sbcglobal.net) :55852 SIP/2.0
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: <009>Via: SIP/2.0/UDP 67.228.77.18 (sip-byod.voipwelcome.com) :5060;branch=0
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: <009>From: sip:ping@voipo.com;tag=e6f60be
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: <009>To: sip:75.45.179.75 (adsl-75-45-179-75.dsl.sfldmi.sbcglobal.net) :55852
      2011-03-09 10:52:38	Local0.Info	192.168.123.1	Mar  9 10:52:38 pf: <009>Call-ID: 9cfc\0x8c\0x9ewM\0xbdn\0x03\0x00\0x00\0x01\0x00\0x00I\0x01\0x00\0x00\0x14\0x00\0x00\0x00=\0x02\0x01\0x00pppoe0\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x01\0xff\0xff\0xff\0xff\0xff\0xff\0xff\0xff\0xa0\0x86\0x01\0x00
      2011-03-09 10:52:43	Local0.Info	192.168.123.1	Mar  9 10:52:43 pf: 00:00:04.542233 rule 1/0(match): block in on pppoe0: (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto UDP (17), length 265)
      
      

      Since I have a rule to allow all UDP traffic on port 5060 to pass to the adapter, I am confused as to why it is getting blocked.

      Thanks for any help…

      1 Reply Last reply Reply Quote 0
      • jimpJ Offline
        jimp Rebel Alliance Developer Netgate
        last edited by

        It may be that the state expired and you're seeing out-of-state traffic hitting the default deny rule.

        Have you tried changing your firewall optimization setting to 'conservative' under System > Advanced?

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • J Offline
          jevo
          last edited by

          Already in the conservative state.

          But if the rule forwards traffic like this to the voip adapter anyways, why would it reject these packets?

          I know I must be missing something obvious, but the provider did say they have run into issues with BSD based firewalls…  I have confidence this can be worked around...just looking for ideas on how to troubleshoot.

          1 Reply Last reply Reply Quote 0
          • W Offline
            wallabybob
            last edited by

            @jevo:

            Since I have a rule to allow all UDP traffic on port 5060 to pass to the adapter, I am confused as to why it is getting blocked.

            TCP and UDP packets have two ports: a source port and a destination port. Your rule description doesn't provide enough information to determine whether the blocked packets match the rule. (The logged packets have a source port of 5060 but varying destination ports. Perhaps your rule specified a destination port of 5060.)

            I know zip about sip so what I'm about to write is entirely speculation. Imagine some downstream of your firewall makes an outgoing access to a sip provider but then goes quite. The firewall will have created a temporary rule to allow responses through the firewall. The "session" stays quiet long enough for the temporary rule to expire. The remote end sends something (perhaps a 'keep alive') and the firewall drops it because the temporary rule that would have allowed that "something" through has expired.

            Depending on what has been logged, you might be able to confirm that speculation.

            Perhaps the firewall rules need a longer expiry time OR the "keep alive" time needs to be reduced.

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