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

    PfSense behind US Robotics: ESP packets from WAN to 224.0.0.1

    Firewalling
    3
    7
    6.4k
    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.
    • M
      manuel
      last edited by

      Hi all, i'm new to the forums and just deployed pfSense yesterday in our office, but let me quickly show you the simple setup:

      
U.S. Robotics ADSL Router @192.168.0.1
      |
      |           |---------------|
      |           |               |
      |           |W             L|       |-----------|
      --------->  |A   pfSense   A|---->  |   switch  |----> ...internal lan... @192.168.1.0/24, Windows PCs, Macs and Printers
                  |N     box     N|       |-----------|
                  |               |
                  |---------------|

									pfSense WAN: 192.168.0.2
									pfSense LAN: 192.168.1.1

      I noticed the firewall log getting a new entry every 2 minutes or so from the USR router interface to a 224.0.0.1 address, quicky filling up the "last 50 entries" page: have you ever experienced such ESP traffic? I never did, that's why i'm asking for your experiences.
      The curious fact is that trying to ping 224.0.0.1 from the LAN, it oddly resolves to a 192.168.1.3 (a MacOsX 10.4.11 machine): trying to ping it from the pfSense's shell box it just fails.
      I already made sure to have the "Block private networks" unchecked from the "Interfaces->Wan" page, so i'm pretty confused on what this could be: anyway, here is the log:

      x Nov 13 17:49:30 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:47:24 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:45:19 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:43:13 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:41:08 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:39:02 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:36:56 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:34:51 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:32:45 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:30:39 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:28:34 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:26:28 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:24:22 WAN 192.168.0.1 224.0.0.1 ESP
      x Nov 13 17:22:17 WAN 192.168.0.1 224.0.0.1 ESP

      Activating the "Block private networks", the firewall block the traffic since triggered by that rule:

      • @33 block drop in log quick on rl0 inet from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"

      deactivating it instead, cause the firewall to drop the packet anyway, triggered by the (hidden) rule:

      • @46 block drop in log quick all label "Default block all just to be sure."

      Do i need to make an explicit rule to allow "private networks" traffic from wan to lan? It seems odd to me..

      Thank you in advance,
      Manuel

      1 Reply Last reply Reply Quote 0
      • M
        manuel
        last edited by

        Ok, this multicast traffic is in fact IGMP v2 traffic and it seems IGMP authentication: "block private networks" unchecked, firewall rull to pass ESP packets from 192.168.0.1 to 224.0.0.1 (all hosts) doesn't pass at all and it's still blocked by the last hidden rule, however, switching from ESP to IGMP works fine and packets are forwarded correctly.

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          http://forum.pfsense.org/index.php/topic,7001.0.html

          Unchecking the "block private networks" checkbox only removes the rule at the very top under WAN.
          This rule says: block anything from private networks.
          This rule is just here to override other rules that might allow private networks in.
          (Such as an "allow any, to my server")

          If you dont create a rule, per default everything gets blocks.
          So if you dont create a rule that allows this traffic in, it will be blocked.

          If you're concerned about the log-entries: you can create a firewall-rule that matches this exact traffic (ESP, 192.168.0.1 to 224.0.0.1), block it and set the rule so it doesnt log. (uncheck the box "log pakets handled by this rule").
          Now this traffic will still be blocked, but wont show up in the log.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • M
            manuel
            last edited by

            @GruensFroeschli:

            http://forum.pfsense.org/index.php/topic,7001.0.html

            Unchecking the "block private networks" checkbox only removes the rule at the very top under WAN.
            This rule says: block anything from private networks.
            This rule is just here to override other rules that might allow private networks in.
            (Such as an "allow any, to my server")

            If you dont create a rule, per default everything gets blocks.
            So if you dont create a rule that allows this traffic in, it will be blocked.

            Yes, i just thought that unchecking that option would create a "pass" rule for it.

            @GruensFroeschli:

            But why would you want to allow this traffic?
            As you said: it appears to be IGMP traffic.
            Since pfSense doesnt support IGMP you dont want to have this stuff in your LAN, do you?

            It seems Skype sometime have some nasty problems with video/audio quality if IGMP traffic is blocked, but not all the time, so i was just experimenting with it.

            @GruensFroeschli:

            If you're concerned about the log-entries: you can create a firewall-rule that matches this exact traffic (ESP, 192.168.0.1 to 224.0.0.1), block it and set the rule so it doesnt log. (uncheck the box "log pakets handled by this rule").
            Now this traffic will still be blocked, but wont show up in the log.

            I really did this too, but using ESP as the protocol rule definition just didn't catch the packets, but specifying IGMP worked fine: i mean, ESP is showed in the default log view so i tried to make rules with that ESP protocol but without success since and the packets were still catched by the "block all" rule: then i switched to raw log entries and the same ESP entries were shown as IGMP ones, so i just changed the rules to match an IGMP protocol and that did it.

            Is it possible the raw log is misinterpreted and that should really read as IGMP as it appears in the raw logs?

            1 Reply Last reply Reply Quote 0
            • GruensFroeschliG
              GruensFroeschli
              last edited by

              My bad… i was thinking about IGRP not IGMP….
              Ignore my text abouve regarding IGMP  ^^"

              I'm not sure if it is a bug.
              Since you say the raw logs display something else than the webGUI-logs it might well be.

              We do what we must, because we can.

              Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

              1 Reply Last reply Reply Quote 0
              • G
                gmax
                last edited by

                Hi

                I thought I would add my 10 cents.

                The packets are MULTICAST packets and belong to the ALLDEVICES (224.0.0.1) multicast group.
                MULTICAST packets are not routed. Because of the way your network is wired (per your diagram), the packets
                originated from your router. You can safely ignore the packets and create a rule to silently drop them.

                You can get more background on the nature of this stuff at:
                http://tldp.org/HOWTO/Multicast-HOWTO.html#toc2

                regards

                1 Reply Last reply Reply Quote 0
                • M
                  manuel
                  last edited by

                  Thank you much gmax, i did know that the 224.0.0.1 was the ALLDEVICES multicast group but i didn't know i could safely drop them: i did it but i was monitoring the network for problems or something else (i experienced some Skype quality problems while dropping these packets in the past but now it's working good, maybe that was a not-so-mature Skype version?): also very thanks for that link, i looked into my trusty Kozierok's tcp/ip guide but it's lacking some information about IGMP.

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