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

    Update pfsense 2.0.1 stable to 2.1 problem with routes

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    74 Posts 16 Posters 30.3k 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.
    • M
      maykel535
      last edited by

      I solved this problem. In the version pfsense 2.1 stable, also add static routes, you also have to add in paragraph rules to allow traffic to that route.

      This well because security have gotten more but if you do not know the routes stop working when updating from 2.0.1 to 2.1 pfsense

      Thanks for all.

      1 Reply Last reply Reply Quote 0
      • V
        vielfede
        last edited by

        Fix  successfully tested!
        Now both vpns work.

        Indeed now I discovered anothter issue on 1:1 NAT and hence I'm still on 2.1-RC1….
        But this will be another thread... we can change this one to [SOLVED]

        1 Reply Last reply Reply Quote 0
        • S
          skenter
          last edited by

          Hi I am facing the same problem. My configuration includes 3 Wan (Wan1,Wan2,Wan3) in one gateway group and 2 lans. My static is like x.x.x.x -> Gw2 through is ignored. Can you give me some more information about the solution? Do I have to add a floating firewall rule? 
          Thank you very much.

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

            @skenter:

            Hi I am facing the same problem. My configuration includes 3 Wan (Wan1,Wan2,Wan3) in one gateway group and 2 lans. My static is like x.x.x.x -> Gw2 through is ignored. Can you give me some more information about the solution? Do I have to add a floating firewall rule? 
            Thank you very much.

            The fix in my December 09 post is only relevant to configs that have OpenVPN instances with comma-separated lists of subnets in the "remote network/s" field. That fix involves changing /etc/inc/filter.inc
            Post more info about your configuration, the order of the rules on each of your LANs and the content of /tmp/rules.debug - that should help sort out where and why the traffic is not being directed as expected.

            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
            • S
              skenter
              last edited by

              Hi thank you for your reply. As you can see from the static route i am trying to route packets with destination 193.193.185.90 from GW OTENET - 192.200.9.1 on interface Wan2. Here https://skydrive.live.com/redir?resid=82D07EFA9D38DD9A!326 you can also see firewall rules and the gateway group regarding multi wan configuration. I found also this post about similar problem http://forum.pfsense.org/index.php/topic,49963.0.html
              Thank you

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

                @skenter:

                Hi thank you for your reply. As you can see from the static route i am trying to route packets with destination 193.193.185.90 from GW OTENET - 192.200.9.1 on interface Wan2. Here https://skydrive.live.com/redir?resid=82D07EFA9D38DD9A!326 you can also see firewall rules and the gateway group regarding multi wan configuration. I found also this post about similar problem http://forum.pfsense.org/index.php/topic,49963.0.html
                Thank you

                I think this is now a "feature" of pfSense 2.1 - in older versions of pfSense, when you sent destination all to a gateway [group], it added a rule just before the gateway rule. That extra rule passed other traffic that it thought was local, without pushing it into the gateway [group]. Now this behaviour is limited to only OpenVPN tunnel networks and the remote networks at the end of those tunnels.

                You need to add a rule before the rule that sends destination * to Gateway:
                Pass source LANnet port * destination 193.193.185.90/31 port * gateway none (*)

                That will pass the matching traffic to the ordinary routing table, where your static route will be used.

                The general principle is to explicitly put in pass rules to match and pass any traffic that needs to use the ordinary routing table (traffic to other local subnets, or subnets reached by static routes, or even private subnets reached across site-to-site VPN links). After these pass rule(s) then put general "destination all" rules that are intended to feed general internet traffic into gateway [groups].

                For example, I my systems, I have all my internal networks across all offices within the 10.42.0.0/16 network (10.42.1.0/24 10.42.2.0/24 …). I put a pass rule on each LAN... from LANnet to 10.42.0.0/16. Then put the rules directing traffic to gateway [groups].

                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
                • S
                  skenter
                  last edited by

                  Hi thank you very much , i think i did it correctly but unfortunately still seems to be a problem.

                  https://skydrive.live.com/redir?resid=82D07EFA9D38DD9A!332&authkey=!AKSOKDzmOxpv6N0

                  Any idea ?  Thank you again for your time.

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

                    If you don't specify a gateway in the rule the it uses the system routing. It seems to using the default gateway.
                    Why it's not using your added route is unclear. What does your routing table look like?

                    If you specify the wan2 gateway in your rule it should work.

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • S
                      skenter
                      last edited by

                      @skenter:

                      Hi thank you very much , i think i did it correctly but unfortunately still seems to be a problem.

                      https://skydrive.live.com/redir?resid=82D07EFA9D38DD9A!332&authkey=!AKSOKDzmOxpv6N0

                      Any idea ?  Thank you again for your time.

                      Hi, I tried this solution but still the same. Is also strange  that although the firewall roule for 193.193.185.90 is before the rule  'Default allow LAN to any rule Lan1' which is the default,  in firewall log it seems that only the defaflt used.  :-
                      https://skydrive.live.com/redir?resid=82D07EFA9D38DD9A!335&authkey=!AC0cgvwbsRBwE1Q

                      Thank you.

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

                        It's not caught by your rule because it is set for ipv4 tcp only. Traceroute uses igmp. Set the protocol to ipv4 any and it should work.

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • S
                          skenter
                          last edited by

                          @stephenw10:

                          It's not caught by your rule because it is set for ipv4 tcp only. Traceroute uses igmp. Set the protocol to ipv4 any and it should work.

                          Steve

                          Steve you save me. Thank you very much.

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