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

    Stale UDP states (udp.single) ?

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    6 Posts 3 Posters 3.4k 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.
    • D
      dhatz
      last edited by

      While doing some testing with the latest 2.1-BETA0, I noticed several UDP states (note: 192.168.100.66 is a VM server running asterisk, and I have a pfsense port-fwd rule which intercepts/forwards DNS traffic to 127.0.0.1) over 20 min after the VM was closed down:

      pfctl -ss | fgrep 192.168.100.66

      all udp sip_srv_ip:5060 <- 192.168.100.66:5060       NO_TRAFFIC:SINGLE
      all udp 192.168.100.66:5060 -> pfsense_wan_ip:35819 -> sip_srv_ip:5060       SINGLE:NO_TRAFFIC
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:44690       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:63425       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:42654       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:31258       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:14731       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:31403       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:41616       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:16957       SINGLE:MULTIPLE
      all udp 127.0.0.1:53 <- 192.168.100.1:53 <- 192.168.100.66:61926       SINGLE:MULTIPLE

      Shouldn't these UDP states have expired according to pf's timeouts ?

      pfctl -st

      tcp.first                   120s
      tcp.opening                  30s
      tcp.established           86400s
      tcp.closing                 900s
      tcp.finwait                  45s
      tcp.closed                   90s
      tcp.tsdiff                   30s
      udp.first                    60s
      udp.single                   30s
      udp.multiple                 60s
      icmp.first                   20s
      icmp.error                   10s
      other.first                  60s
      other.single                 30s
      other.multiple               60s
      frag                         30s
      interval                     10s
      adaptive.start            13200 states
      adaptive.end              26400 states
      src.track                   600s

      Note: Initially there were several more UDP states MULTIPLE:MULTIPLE which expired correctly after a minute or so.

      1 Reply Last reply Reply Quote 0
      • D
        dhatz
        last edited by

        Re-checking periodically, it seems that after some time (1.5hr) the above mentioned states are gone.

        1 Reply Last reply Reply Quote 0
        • D
          dhatz
          last edited by

          Any ideas how I could troubleshoot such an issue ?

          1 Reply Last reply Reply Quote 0
          • S
            seattle-it
            last edited by

            Yeah I notice that happens as well with SIP/5060 when the WAN link goes down, or when the connection is severed on the network on my PBX box.

            My tech blog - seattleit.net/blog

            1 Reply Last reply Reply Quote 0
            • D
              dhatz
              last edited by

              @seattle-it:

              Yeah I notice that happens as well with SIP/5060 when the WAN link goes down, or when the connection is severed on the network on my PBX box.

              The problem of pfsense not killing UDP/5060 MULTIPLE:MULTIPLE states on WAN IP change, is probably a different issue, see the posts in the NAT subforum.

              In the case I mentioned in my opening post, there was no WAN IP change (WAN IP is static) and the affected states were NO_TRAFFIC:SINGLE

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                cranking up the pf debug level is probably your best bet to troubleshoot.

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