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

    Unable to ping LAN from OPT subnet

    Scheduled Pinned Locked Moved Firewalling
    12 Posts 3 Posters 2.7k 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.
    • A
      adino
      last edited by

      Please I need some help. I am a newbie to pfSense but I do understand some networking so apologies if this is not the right forum or if the question sounds dumb.

      I have a pfsense setup that looks like the one in the attachment below (Network_Setup).
      Here's the setup:

      • WAN: em0 - 172.16.4.4

      • LAN: em1 - 192.168.1.1

      • CHILDNET1: em2 - 192.168.2.1

      • CHILDNET2: em3 - 192.168.3.1

      I've attached screenshots of all the Firewall rules. The entire setup is running on 4 VirtualBox VMs, including pfSense. I set up pfSense with 4 virtual NICs. Each of the other 3 VMs are Windows Server 2008 r2 machines. They are all on internal networks: Root is on intnet, Child1 is on childnet1, and Child2 is on childnet2. pfSense has one NIC bridged (the WAN link), while each of the other 3 NICs are on each of the internal networks. All 3 server VMs are able to connect to the internet. However, I am unable to ping 192.168.3.2 from 192.168.1.2. I can ping 192.168.3.1 from 192.168.1.2 but I suppose that makes sense since pfSense considers 192.168.1.1, 192.168.2.1 and 192.168.3.1 as loopback addresses. The weird thing is that I can ping 192.168.1.2 from 192.168.3.2! Can anyone please help explain what is going on?

      By the way, this is a lab setup and I'm trying to set up 3 domain controllers on three different networks so I can test out some windows configuration. Also, VirtualBox is running on an Ubuntu Linux 14.04 machine.

      Thank you!

      Network_Setup.png
      Network_Setup.png_thumb
      WAN_Rules.png
      WAN_Rules.png_thumb
      LAN_Rules.png
      LAN_Rules.png_thumb
      CHILDNET1_Rules.png
      CHILDNET1_Rules.png_thumb
      CHILDNET2_Rules.png
      CHILDNET2_Rules.png_thumb

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        Check your interfaces to make sure that they aren't blocking private network space.  Interfaces - (IF Name) - Private Networks - Block private networks.

        1 Reply Last reply Reply Quote 0
        • A
          adino
          last edited by

          Just checked. Only WAN is set to block private network space but none of the interfaces are set to block private network space. Should I uncheck the WAN setting?

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            No, leave it as is.  Do you have firewall rules in place that allow these subnets to talk to each other?  By default, only LAN has WAN access and none of them can access each other.  I assume that you added rules to allow each OPT (child1,2) interface to talk to WAN, but do you have rules so that LAN can talk to CHILDNET1 and vice versa?

            1 Reply Last reply Reply Quote 0
            • A
              adino
              last edited by

              Hmm… I thought I already did that. Isn't that what the attachments (LAN_Rules.png, CHILDNET1_Rules.png, CHILDNET2_Rules.png) show? Or am I missing something here?

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by

                No, I'm stupid.  I forgot about them as they were above my browser window.  I do this often when I'm bouncing between problems.  Is it possible that software firewall on 3.2 is blocking the pings?  Some of your rules are strange.  I would start off by removing all rules on LAN (except the antilockout rule), CHILD1 and CHILD2.  Then add an Allow All to Any on all three interfaces.  See if you can ping then.  Once oyu have established connectivity, then you can start applying restriction rules.

                1 Reply Last reply Reply Quote 0
                • A
                  adino
                  last edited by

                  Ah KOM! You're not the stupid one… I am the stupid one! Windows Firewall was the cause of my problems. #facepalm
                  I left the rules as they are in the pictures and I enabled packet capture on all servers and was able to determine that the packets were indeed getting to the right destination, only the destination was not responding! I turned off Windows Firewall and I was able to get responses to the pings.

                  Thank you! :)

                  1 Reply Last reply Reply Quote 0
                  • KOMK
                    KOM
                    last edited by

                    You still have some funny rules there but at least your main problem is solved.

                    1 Reply Last reply Reply Quote 0
                    • A
                      adino
                      last edited by

                      I want to get this right. So, you say I should remove all rules eh?

                      1 Reply Last reply Reply Quote 0
                      • A
                        adino
                        last edited by

                        KOM, I just did what you said. I deleted all rules on LAN (except for anti-lockout rule), CHILDNET1 and CHILDNET2. Then I added an Allow Any to Any on all three interfaces. I am able to ping all servers and everything works just well.

                        1 Reply Last reply Reply Quote 0
                        • DerelictD
                          Derelict LAYER 8 Netgate
                          last edited by

                          This is the key concept you need to grasp:

                          Be sure that the rules are on the proper interface. Imagine sitting inside of the pfSense box. Sure, it's a little crowded in there, but this can help. Imagine packets flying in from the different networks that the pfSense box ties together. The rules will be placed on the interface they entered from. If a packet is going from the LAN to the pfSense box, then out to the Internet, the rules still enter on the LAN. If a packet is coming from the Internet to the pfSense box, the rule goes on the WAN interface.

                          https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

                          See, for example, on CHILDNET1 where you have rules allowing traffic with sources FROM LAN net and CHILDNET2 Net?  That's pretty much impossible.  Rules on CHILDNET1 determine what traffic INTO the CHILDNET1 interface (from the CHILDNET1 network) is allowed.  So if you want CHILDNET1 to be allowed access to the internet but not LAN or CHILDNET2 you would:

                          reject src CHILDNET1 net dest LAN net
                          reject src CHILDNET1 net dest CHILDNET2 net
                          pass src CHILDNET1 net dest any

                          It's pretty much impossible to have the CHILDNET1 interface receive traffic with a source address FROM LAN net or CHILDNET2 net unless you do some pretty specific things, the likes of which most here would say, "that's a broken config."

                          You don't have to worry about return traffic for the connections once the connection is let into pfSense.  The stateful firewall handles all that.

                          Chattanooga, Tennessee, USA
                          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                          Do Not Chat For Help! NO_WAN_EGRESS(TM)

                          1 Reply Last reply Reply Quote 0
                          • A
                            adino
                            last edited by

                            Oh! I see! Now it makes sense. Thanks for the clarification.

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