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

    Routing problem with pfsense!

    1.2.1-RC Snapshot Feedback and Problems-RETIRED
    3
    6
    5.2k
    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
      TheT
      last edited by

      Hello Everyone,

      I have the problem that I can't resolve, please check the note below:

      Version:  1.2.1RC1

      Laptop <-> switch1 <-> LAN (172.10.11.x/24) [pfsense (dell 1950 2 bce nics + 4 intel pro nics)] WAN <->  switch2 <-> LAN 172.10.10.x/24 (Juniper FW) WAN] <-> ISP

      Pfsense WAN IP:  172.10.10.250
      Pfsense Gateway for WAN at switch2 is 172.10.10.1 - which is Juniper FW internal gateway for the servers behind Juniper

      Gateway Internal at pfsense LAN is 172.10.11.1  thus my laptop has this gateway.

      Created policy from WAN to allow anyone from outside to access WAN Address on port 443 (management gui of pfsense) and also allow PING to Wan address.

      The problem:
      –-------------------

      If I define pfsense's WAN with a gateway of  "172.10.10.1"    my laptop can access the NET and go out to any server with out any problem,

      BUT  from servers connected to "switch2"  they can not ping or telnet to pfsense WAN's address

      Knowing I must define pfsense WAN settings with a gateway,  I decided to backup the config and manually edited the config file to have WAN's gateway defined as "anytexthere"  - then restore the config file to pfsense and reboot.

      After the above step,  then any servers from swtich2 can ping and/or telnet to port 443 of the wan address -  but from internal ie my laptop can not access the the NET.

      Any idea on how to fix this problem is much appreciated.

      Note: I tried this with 1.3alpha and has the same problem.

      Regards,

      Kenny

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        It is a know problem and was introduced lately in both 1.2.1 and 1.3 it is being worked on.
        For now either you need a router inbetween or need to modify pfSense code to not add reply-to to the rules.

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

          Thank you for the reply.  Adding a router is hard now, which file should I modify and change what in order to support?  Is possible for me to get an older 1.2 iso in which it can support new drivers without this routing problem?

          Thank you,

          Kenny

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

            It's actually a bug fix…problem is it created a different bug.

            in your situation you probably want to revert to the previous behavior, unless you're running multi-WAN you won't see the issue this change fixes. open /etc/inc/filter.inc and go down to line 1576. You'll see the following, remove all 4 of these lines.

            /* do not process reply-to for gateway'd rules */
            if(($rule['gateway'] == "") and ($ri != "") and ($rg != "")) {
            $aline['reply'] = "reply-to (" . $ri . " " . $rg . ") ";
            }

            Save the file, then edit and save a firewall rule to make it regenerate the ruleset.

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Can you please test a snapshot later than 11-Aug-2008 12:27  it has a fix for this.

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

                Thank you,

                I can ping from the wan and  access the port too.

                Kenny

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