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

    OPT interfaces not passing traffic or responding to pings

    Scheduled Pinned Locked Moved General pfSense Questions
    8 Posts 4 Posters 9.1k 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.
    • C
      Cougar281
      last edited by

      I'm not exactly sure where this fits because I don't know what I'm missing, so I'm putting it in 'general'.

      I'll start by saying this is not the first pfSense firewall I've set up. I have one at my mothers house and one at home with a S2S VPN between the two.

      The one at my house is a VMWare virtual guest with 5 virtual interfaces. I had no trouble setting it up and it's working great.

      I'm trying to set up a pfSense firewall for another 'project' and I can't get it to work to save my life. I did a default install of pfSense on the guest, set up the LAN & WAN and they work fine. The host on the LAN interface can ping the pfSense interface, can get to the internet, etc. The 'OPT' interfaces are another story. They won't do anything. The interfaces won't respond to pings, they don't pass traffic to the internet. Nothing. I have the WAN, LAN and 6 'OPT' interfaces. At the moment, I only have plans to use 'OPT1' & 'OPT2', but I added the others so if I need more, I can just assign them.

      I essentially duplicated my working config, minus the obvious rules that are specific to my main FW, with no luck. I've attached my configm the XML renamed to a .txt extension if that would help.

      Let's call the interfaces LAN, WAN, 'OPT1' and OPT2'.

      I set up rules blocking traffic from OPT1 to LAN & OPT2, and from OPT2 to LAN and OPT1 as I don't want any of the 'OPT' interfaces accessing each other or the 'LAN'.

      The Third rule is an 'Allow {net} all' ({net} being the subnet assigned to the interface) rule, essentially duplicating the LAN's default 'LAN to any' rule so if it isn't an attempt to get to one of the blocked subnets, then that rule applies and it is sent out on its way.

      I even tried not having the block rules and simply allowing {OPT Net} -> all and it still didn't work .

      I looked at some logs and they show a lot blocks. Essentailly, everything to every 'OPT' interface, even pings to the OPT interface itsself is blocked. Even with the 'allow all' rule.

      For grins, to see if it was the guest VM that belonged attached to the 'OPT' interface, I changed it's IP and moved it to the LAN and it worked perfectly. For whatever reason, the 'OPT' interfaces don't want to work.

      Does anyone have any idea what I'm missing? I didn't have this much trouble setting up my pfSense VM. I didn't need to add any special rules to get the interfaces to respond to pings or anything. Like I said, I duplicated the 'generic' rules that are on my funcioning pfSense to the new one, but no luck. This is driving me NUTS. What the heck am I missing?

      Edit: From the pfSense, I can ping the hosts on the 'OPT' interfaces, but the hosts can't ping the pfSense.
      config-pfsense.localdomain-20120817043313.txt

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        The rules in your config are only allowing TCP. But

        Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response.

        It sounds like in this case you just need to edit the rule to allow "any" protocol - TCP, UDP, ICMP and any other fancy ones that come along.
        You can ping out from pfSense because that traffic is initiated in the opposite direction, and the response to the ping is then part of a known state/flow on the firewall, so doesn't get subjected to the rules.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

          @phil.davis:

          The rules in your config are only allowing TCP. But

          Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response.

          It sounds like in this case you just need to edit the rule to allow "any" protocol - TCP, UDP, ICMP and any other fancy ones that come along.
          You can ping out from pfSense because that traffic is initiated in the opposite direction, and the response to the ping is then part of a known state/flow on the firewall, so doesn't get subjected to the rules.

          Except I don't have any ICMP rules on my existing pfSense, nor are there any ICMP rules on the 'LAN' of the new one, yet the LAN interface can be pinged and pinged through, and all the interfaces on my existing pfSense can be pinged and pinged through. Ping aside, the rules should be allowing other traffic to pass even if ICMP is blocked for whatever reason. Like I said, the block/allow rules I set up on this one are identical to rules I set up on my existing one that work there, but not on this one.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            You have allowed only TCP so you will not be able to use DNS, which is UDP.
            If you change your rules on OPT1 and OPT2 to: protocol any it will work. You can always add rules or edit it later to tighten things down later.

            Steve

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

              @stephenw10:

              You have allowed only TCP so you will not be able to use DNS, which is UDP.
              If you change your rules on OPT1 and OPT2 to: protocol any it will work. You can always add rules or edit it later to tighten things down later.

              Steve

              Yeah, I'm an idiot. I just realised what I did a little while ago. :-[

              Now that I have that all fixed and working as it should, I just want to be sure I'm blocking access to the GUI from the OPT interfaces in the best/proper way.

              I set up block rules at the top of the list to block traffic from the OPT1 subnet destined for the OPT1 address on port 80 & 443. That seems to work. Is that the best or only way to restrict access to the GUIon those networks?

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                The web GUI is available on all the interfaces so you have to careful to block that. For example your may have blocked access to OPT1 interface from OPT1 subnet but users from OPT1 subnet will still be able to access the GUI on OPT2 interface.

                Rather than trying to block the stuff I don't want I take the approach of only allowing stuff I do want and let the default block everything rule take care of the rest.

                I first setup an alias called LOCAL with all my internal subnets in it, 192.168.1.0/24, 192.168.2.0/24 etc. Because I'm lazy I actually just put 192.168.0.0/16  ;)

                Then I add allow rules to my OPT interfaces with destination !LOCAL. This way only traffic to the internet is allowed. Additionally I add a rule to allow traffic to the interface for DNS forwarding, UDP port 53, otherwise users get no DNS. From there I can can add rules at my discretion for specific access to local services etc. I know that unless I have allowed it it is blocked.

                Steve

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

                  Well, in addition to blocking OPTx's subnet from accessing OPTx's interface address on 80 & 443, I also have block rules in on all the OPT interfaces blocking all traffic from their own subnets to the other OPT subnets and the LAN subnet. After all those rules is the 'Allow OPTx any' rule so if it gets past the block rules, it's destined for the internet and thus is allowed. Basically, I don't want to restrict anything internet bound, but I don't want the OPT interfaces to be able to access the LAN or each other.

                  My rules look like this:
                  Block  TCP  OPT1 net  *  OPT1 address  80 (HTTP)  *  none         
                  Block TCP  OPT1 net  *  OPT1 address  443 (HTTPS)  *  none         
                  Block    *  OPT1 net  *  OPT2 net  *  *  none         
                  Block    *  OPT1 net  *  LAN net  *  *  none         
                  Allow    *  OPT1 net  *  *  *  *  none

                  The other OPT interfaces are the same except for the source & destination being appropriate to the given interface.

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

                    It works now?

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