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

    Ping error: Invalid Argument

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 2 Posters 18.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.
    • R
      Rafael
      last edited by

      Hello!

      My OPT1 interface is not working. It has 10.10.140.41 ip address, and when I ping 10.10.140.254, it does not work and the answer is: Invalid Argument.

      LAN's ip address is 10.10.170.254.

      10.10.140.0/24 is network that I need reach from 10.10.170.0/24.

      Thanks!

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

        Can you draw a diagram?
        I dont really get, which subnet is where.

        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
        • R
          Rafael
          last edited by

          I hope this diagram help us….

          The network that is connected to the OPT1 interface, its a network that already has its own gateway. I just want to route traffic from LAN to OPT1 network. But I can't even ping any host on 10.10.140.0/24 network.

          Thanks!
          Rafael

          Diagram1.jpg
          Diagram1.jpg_thumb

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

            Um…. this will never work.
            How are your clients in the 10.10.140.x/24 subnet supposed to know the route to the 10.10.170.x/24 subnet if they have another gateway?

            You have several possibilities to solve this.
            1: set the gateway to the OPT1 IP. --> the easiest. But if you NEED to have another gateway, not applicable in your case.
            2: create static route entries on the clients in the 10.10.140.x/24 subnet. Point the 10.10.170.x/24 subnet to the OPT1 IP . --> not recommended.
            3: create a static route entry on the gateway in your 10.10.140.x/24 subnet. --> doable. i would go with this way.
            4: enable NAT from 10.10.140.x/24 to 10.10.170.x/24 --> like this requests from your LAN to the OPT1 subnet appear as if from the OPT1-interface itself. --> you only want that if you need access from LAN subnet to the OPT1 subnet. Access from OPT1 subnet to the LAN subnet is only possible if you create other NAT entries from OPT1 to LAN. in my opinion as good as the 3rd solution, but requires knowledge about NAT. Also the source will always appear as if fromt the router interface itself. --> not good in many cases.

            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
            • R
              Rafael
              last edited by

              to make things easy, I made another topology that I believe is better than the other one…

              I got Firewall1 and Firewall2, and what I want is make both LANs reach themselves... Then I created another network to connect Firewall1 to Firewall2... I also created an static route on both Firewalls:

              Firewall1 -> when destiny is 10.10.140.0/24 goes through 10.20.101.2 (OPT1)
              Firewall2 -> when destiny is 10.10.170.0/24 goes through 10.20.101.1 (OPT1)

              Looks like things are okay, but i can't ping from Firewall1 to Firewall2 and even from Firewall2 to Firewall1. I was using a VLAN on my switch and to make sure there was no pŕoblem in "the way" (cables, switches) i made a cross cable to connect the firewalls directly.

              Diagram1.jpg
              Diagram1.jpg_thumb

              1 Reply Last reply Reply Quote 0
              • R
                Rafael
                last edited by

                I forgot to say that the "Invalid Argument" error message is not appearing any more….
                just "100% packet lost"....

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

                  Did you create rules on the respective interfaces that allow traffic?
                  ie. on the 10.20.101.2 interface you have to create a rule that allows traffic to the 10.10.170.0/24 ubnet if the source is 10.10.140.0/24

                  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
                  • R
                    Rafael
                    last edited by

                    Both OPT1 interfaces were already allowing traffic from any to any…

                    Firewall1 can't ping Firewall2 through directly connected interfaces... It seems like OPT1 interfaces are blocked or something like that...

                    Couple days ago I've tried to build a multi-wan Firewall and the same thing happened: OPT1 couldn't find its gateway, and it was also directly connected with correct ip addressing...

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

                      Can you show screenshots of your OPT firewall rules?

                      If you cannot ping the interface directly you missconfigured the firewall rule.

                      You say you connect the interfaces directly.
                      Did you make sure that you're using a crossover cable?

                      Can you verify that you can ping the interface through putting a computer in front of the OPT interface and ping it?

                      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
                      • R
                        Rafael
                        last edited by

                        I did make sure that I'm using a crossover cable, and I also checked that it is working fine…
                        I never saw something like that...

                        Here are the screenshots of Firewall1 and Firewall2 OPT rules. There is no comunication between both interfaces. I feel like I'm doing some idiot mistake...

                        If you could help, I will be glad.

                        Firewall1.JPG
                        Firewall1.JPG_thumb
                        Firewall2.JPG
                        Firewall2.JPG_thumb

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

                          You missunderstand what the gateway means.

                          It means if traffic on this interface comes in and matches the rule it will be send to the gateway.
                          If you set * (default) it will be processes by the routingtable of pfSense.
                          Right now you force the traffic somewhere.
                          But inbound on the interface itself that doesnt make any sense.

                          As a rule of thumb you can say: never edit the gateway unless you REALLY know that you want to force traffic this way.
                          It's usually better to add static routes to the routing table and let the gateway on *.

                          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
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.