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.
    • V
      vielfede
      last edited by

      @stephenw10:

      Hmm, interesting stuff. As I think I said earlier I have 'negate networks' unchecked and added my own rules. Probably why I've not seen any issues.

      Are you sure this is an issue with what ends up in the <negate_networks>table rather than what rules are generated from it?

      Steve</negate_networks>

      As you can see above, probably, the issue is due to the <vpn_networks>because  It does not list all vpn networks (e.g. there isn't 10.106.100.0) and (I think) <negate_networks>is made up of <vpn_networks>+other stuff…</vpn_networks></negate_networks></vpn_networks>

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

        From my reading of the code, <negate_networks>now only contains the same as <vpn_networks>- other stuff is no longer put in it.
        What is special about the VPN networks that are not listed in the 2.1-RELEASE rules.debug?
        Are they not listed in "IPv4 Remote Network/s" box in the server/client config?

        The Remote Network/s box can now have a comma-separated list of networks. I just discovered that if I have more than 1 network there, then none of them appear in vpn_networks. If I cut it down to just 1 network, then it appears in vpn_networks. That is a bug. Got to go right now, back can look at it in a day or so, or maybe someone else can look at the code before then…</vpn_networks></negate_networks>

        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
        • V
          vielfede
          last edited by

          In my conf, I specify 2nd remote networks in OpenVPN server "advanced configuration" field as "in the previous (old) way", and hence this is because I can get just the first VPN to work.
          Fake care of the following:( in my conf) disabling multiwan get both vpn to work!

          Meantime I submitted a bug on https://redmine.pfsense.org/issues/3309

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

            The Remote Network/s box can now have a comma-separated list of networks. I just discovered that if I have more than 1 network there, then none of them appear in vpn_networks. If I cut it down to just 1 network, then it appears in vpn_networks. That is a bug. Got to go right now, back can look at it in a day or so, or maybe someone else can look at the code before then…

            https://github.com/pfsense/pfsense/pull/850 fixes the problem when there is a comma-separated list in "Remote Network(s)".

            In my conf, I specify 2nd remote networks in OpenVPN server "advanced configuration" field as "in the previous (old) way"

            Hmmm - perhaps there used to be code that found the entries in the advanced configuration also? But I don't think so. Anyway, with the fix above you will be able to put lists of Remote Network(s) and have it come through correctly to vpn_networks and negate_networks.

            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
            • V
              vielfede
              last edited by

              @phil.davis:

              The Remote Network/s box can now have a comma-separated list of networks. I just discovered that if I have more than 1 network there, then none of them appear in vpn_networks. If I cut it down to just 1 network, then it appears in vpn_networks. That is a bug. Got to go right now, back can look at it in a day or so, or maybe someone else can look at the code before then…

              https://github.com/pfsense/pfsense/pull/850 fixes the problem when there is a comma-separated list in "Remote Network(s)".

              In my conf, I specify 2nd remote networks in OpenVPN server "advanced configuration" field as "in the previous (old) way"

              Hmmm - perhaps there used to be code that found the entries in the advanced configuration also? But I don't think so. Anyway, with the fix above you will be able to put lists of Remote Network(s) and have it come through correctly to vpn_networks and negate_networks.

              Thanks Phil.
              I fixed the problem on filter.inc on pfSense test server and now vpn_networks and negates_networks seem ok (using comma separated remote network on vpn_server config).
              Now I should to test it on production…. I hope to be able to do it on next monday....
              I'll let you know...

              1 Reply Last reply Reply Quote 0
              • F
                frhack
                last edited by

                After upgrading to 2.1 I encountered routes problem.

                My configuration is:

                2 WAN:

                • WAN
                • WAN_VOIP

                1 DMZ with:
                  - 1 web server host forced to use WAN gw (WAN gw specified in DMZ firewall rule)
                  - 1 asterisk host forced to use WAN VOIP gw (WAN_VOIP gw specified in DMZ firewall rule)

                2 LAN:

                • LAN forced to to use WAN VOIP (WAN GW specified in LAN FW rule)
                • LAN_VOIP forced to use WAN (WAN VOIP GW specified in LAN_VOIP FW rule)

                After upgrade to 2.1: no connection from internet to  DMZ asterisk, DMZ webserver

                At this time I downgraded to 2.03

                Thanks

                –
                Francesco

                1 Reply Last reply Reply Quote 0
                • 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.