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

    Weird Packets that cannot be blocked.

    General pfSense Questions
    4
    10
    545
    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.
    • T
      TheGeek
      last edited by

      Hello,

      I have pfsense running on a network that it is not connected to the internet.
      And while everything seems to be working as it should (NAT, firewall rules, etc) i saw with Packet Capture a lot of packets leaving the WAN interface while they were not supposed to.
      And they are a lot of packages per minute.
      All off them have this form: X.X.X.X (Wan IP of PfSense) >202.12.27.33.500: UDP, length 360
      And i also see the same traffic from a Domain Controller i have behind NAT, but without NATing the IP and showing the real one.
      eg. 172.16.0.1 (Internal IP) >202.12.27.33.500: UDP, length 360
      I tried to block UDP port 500 on pfSense and also add a deny outgoing rule on port 500 on my Domain Controller, but still the packets are passing the firewall.

      Any idea?

      1 Reply Last reply Reply Quote 0
      • NogBadTheBadN
        NogBadTheBad
        last edited by

        Not sure why you are seeing port 500, it's a DNS root server.

        https://www.iana.org/domains/root/servers

        mac-pro:~ andyk$ dig -x 202.12.27.33

        ; <<>> DiG 9.9.7-P3 <<>> -x 202.12.27.33
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6047
        ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 4096
        ;; QUESTION SECTION:
        ;33.27.12.202.in-addr.arpa. IN PTR

        ;; ANSWER SECTION:
        33.27.12.202.in-addr.arpa. 86131 IN PTR M.ROOT-SERVERS.NET.

        ;; AUTHORITY SECTION:
        27.12.202.in-addr.arpa. 86131 IN NS ns.tokyo.wide.ad.jp.
        27.12.202.in-addr.arpa. 86131 IN NS mango.itojun.org.
        27.12.202.in-addr.arpa. 86131 IN NS ns-wide.wide.ad.jp.

        ;; Query time: 43 msec
        ;; SERVER: xxxx:xxxx:xxxx:2::1#53(xxxx:xxxx:xxxx:2::1)
        ;; WHEN: Tue Oct 10 19:40:41 BST 2017
        ;; MSG SIZE  rcvd: 171

        mac-pro:~ andyk$

        Andy

        1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

        1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator
          last edited by

          Yeah 500 is not dns.. UDP 500 would normally be isakmp, why you would be sending it to a root server IP??

          Your saying your also seeing it from a AD DC.. And its sending out your WAN without natting the rfc1918 to your public?

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.03 | Lab VMs 2.7.2, 24.03

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

            Could be those hosts are compromised and trying to DoS the root DNS server(s).

            After adding a block rule, make sure to reset the states.

            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
            • NogBadTheBadN
              NogBadTheBad
              last edited by

              Maybe do a packet capture and set wireshark to decode UDP 500 as DNS.

              Andy

              1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                If they were trying to dos, wouldn't they be sending malformed traffic to dns on 53?  But sure anything is possible I guess.

                As jimp mentioned if your going to put in block rules, you should clear the states after you put in rule.. Could you post up the rules your putting in place to block this traffic.. So we can see if they are correct.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.03 | Lab VMs 2.7.2, 24.03

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

                  @johnpoz:

                  If they were trying to dos, wouldn't they be sending malformed traffic to dns on 53?  But sure anything is possible I guess.

                  As jimp mentioned if your going to put in block rules, you should clear the states after you put in rule.. Could you post up the rules your putting in place to block this traffic.. So we can see if they are correct.

                  Traffic is traffic, I don't expect much of anything that script kiddies and people that perform DoS attacks do to make sense. udp/500 is commonly allowed outbound, so it may slip by unnoticed. Though I would expect udp/500 to get dropped long before it reached the root server.

                  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
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    Very true ;)  But since 500 a static port for nat on pfsense, prob couldn't be sending much traffic from clients behind anyway.

                    I have never looked into this… But what exactly happens if client 1 sends out isakmp and then client 2 and 3 all try doing it as well with port 500?  Since its listed as a static port how does pfsense handle multiple clients all wanting to use that port?

                    Clearly off topic but the traffic on isakmp got me thinking of what would happen.. Guess I could always lab it an see ;)

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.03 | Lab VMs 2.7.2, 24.03

                    1 Reply Last reply Reply Quote 0
                    • T
                      TheGeek
                      last edited by

                      @johnpoz:

                      Yeah 500 is not dns.. UDP 500 would normally be isakmp, why you would be sending it to a root server IP??

                      Your saying your also seeing it from a AD DC.. And its sending out your WAN without natting the rfc1918 to your public?

                      Exactly.
                      To give some more info about the network.
                      I have IPSEC on my network.
                      And i see tha same kind of traffic coming from both the Firewall itself and the DC.
                      UDP 500 to this root DNS ip.
                      This is why it is weird.
                      Even after disconnecting the DC, the Firewall kept sending these packets.
                      So, maybe the DC is compromised, but what about the pfSense?

                      And here is a capture:
                      07:32:25.538773 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:25.741954 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:26.023376 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:26.226275 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:26.304458 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
                      07:32:28.538751 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:28.742394 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:29.038768 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:29.307334 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:30.320302 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:31.335691 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:31.538756 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:31.757434 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:32.038801 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:33.964202 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
                      07:32:34.335655 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:34.538719 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:34.757414 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:34.960600 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
                      07:32:35.038844 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:35.960667 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
                      07:32:37.335806 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:37.538648 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:37.757423 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
                      07:32:38.054323 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380</wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan>

                      1 Reply Last reply Reply Quote 0
                      • T
                        TheGeek
                        last edited by

                        And…it is fixed.
                        No clue how.
                        I just restarted the firewall. (I guess something i should have done first).  ::)

                        Thanks everybody for your time!

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post