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

    Multi WAN with same gateway IP intereferes with balancing

    Scheduled Pinned Locked Moved Routing and Multi WAN
    15 Posts 7 Posters 5.8k 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
      mewsense
      last edited by

      @jimp:

      Having two interfaces with the same gateway is not supported. IF they are both PPPoE it may work by chance on occasion but only if you set custom (different!) monitor IP addresses for both gateway entries.

      Why is that? I have two ADSL  lines from my ISP and sometimes both WAN interfaces are assigned the same gateway IP. Could this be added as a feature request? I tried 2.2 RC and get the same issue. As you recommended, I have now manually set two different gateway monitor IPs that my connections get assigned, and we'll see how it works out. Notice that when the gateways are different IPs it works fine:

      Names have changed because I rebuilt pfSense with 2.2 RC.

      1 Reply Last reply Reply Quote 0
      • M
        mewsense
        last edited by

        @rcampbell:

        Can you post a screenshot of your firewall rules for the LAN interface?

        There you go.

        1 Reply Last reply Reply Quote 0
        • N
          netblues
          last edited by

          Having two interfaces with the same gateway is not supported. IF they are both PPPoE it may work by chance on occasion but only if you set custom (different!) monitor IP addresses for both gateway entries.

          Hi.
          I'm running latest stable 2.1.5-RELEASE (amd64)
          built on Mon Aug 25 07:44:45 EDT 2014
          FreeBSD 8.3-RELEASE-p16
          with two PPPoE with same (dynamicly assigned) gateway. I have put different monitor ip addresses for both gateway entries and both ping.  Still if one is connected, the second one will cycle between getting and ip and then dropping in a about 5 sec cycle.
          I've even tried setting up static routes for specific /32 monitor ip's for specific interfaces, with no success.

          When you say may work by chance, are there other parameters  that affect this?

          After seeing the bug fix below, is there a possibility that this bug fixed in 2.2 exists in 2.15?
          https://redmine.pfsense.org/issues/4040

          Regards

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

            I see I am not the only one having this issue when duplicate gaeway is assigned by ISP.  I am on latest formal release of PFSense 2.2.2

            Anyone know how to implement the  -iface option in routing, the one talked about in that bugfix link posted?

            Roofus

            3.jpg
            3.jpg_thumb

            1 Reply Last reply Reply Quote 0
            • N
              netblues
              last edited by

              After upgrading to 2.3,  the issue now seems to be resolved
              Same gateway, two interfaces, No more drops, and traffic load balancing works too

              Great

              1 Reply Last reply Reply Quote 0
              • M
                mrvanity
                last edited by

                @netblues:

                Hi.
                I'm running latest stable 2.1.5-RELEASE (amd64)
                built on Mon Aug 25 07:44:45 EDT 2014
                FreeBSD 8.3-RELEASE-p16
                with two PPPoE with same (dynamicly assigned) gateway. I have put different monitor ip addresses for both gateway entries and both ping.  Still if one is connected, the second one will cycle between getting and ip and then dropping in a about 5 sec cycle.

                It seems that this bug has returned in 2.3.2 with a vengeance.
                In a 2.3 ALPHA Built 28 Dec 2015 snapshot, it worked like a charm.
                in 2.3.2. the problem is described as is , in your quote.

                Attached log, during the problem

                Aug 11 14:15:48 	ppp 		[opt1] IPADDR 87.202.87.162
                Aug 11 14:15:48 	ppp 		[opt1] 87.202.87.162 is OK
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: SendConfigReq #15
                Aug 11 14:15:48 	ppp 		[opt1] IPADDR 87.202.87.162
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: rec'd Configure Ack #15 (Req-Sent)
                Aug 11 14:15:48 	ppp 		[opt1] IPADDR 87.202.87.162
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: state change Req-Sent --> Ack-Rcvd
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: rec'd Configure Request #202 (Ack-Rcvd)
                Aug 11 14:15:48 	ppp 		[opt1] IPADDR 80.106.108.46
                Aug 11 14:15:48 	ppp 		[opt1] 80.106.108.46 is OK
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: SendConfigAck #202
                Aug 11 14:15:48 	ppp 		[opt1] IPADDR 80.106.108.46
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: state change Ack-Rcvd --> Opened
                Aug 11 14:15:48 	ppp 		[opt1] IPCP: LayerUp
                Aug 11 14:15:48 	ppp 		[opt1] 87.202.87.162 -> 80.106.108.46
                Aug 11 14:15:48 	ppp 		[opt1] IFACE: Up event
                Aug 11 14:15:48 	ppp 		[opt1] IFACE: Rename interface ng3 to pppoe1
                Aug 11 14:15:48 	ppp 		[opt1] IPV6CP: rec'd Configure Request #4 (Ack-Rcvd)
                Aug 11 14:15:48 	ppp 		[opt1] IPV6CP: SendConfigAck #4
                Aug 11 14:15:48 	ppp 		[opt1] IPV6CP: state change Ack-Rcvd --> Opened
                Aug 11 14:15:48 	ppp 		[opt1] IPV6CP: LayerUp
                Aug 11 14:15:48 	ppp 		[opt1] 020c:29ff:fe4b:ed0f -> 0090:1a00:01a3:1a05
                Aug 11 14:15:49 	ppp 		[opt1_link0] LCP: rec'd Terminate Request #172 (Opened)
                Aug 11 14:15:49 	ppp 		[opt1_link0] LCP: state change Opened --> Stopping
                Aug 11 14:15:49 	ppp 		[opt1_link0] Link: Leave bundle "opt1"
                Aug 11 14:15:49 	ppp 		[opt1] Bundle: Status update: up 0 links, total bandwidth 9600 bps
                Aug 11 14:15:49 	ppp 		[opt1] IPCP: Close event
                Aug 11 14:15:49 	ppp 		[opt1] IPCP: state change Opened --> Closing
                Aug 11 14:15:49 	ppp 		[opt1] IPCP: SendTerminateReq #16
                Aug 11 14:15:49 	ppp 		[opt1] IPCP: LayerDown
                Aug 11 14:15:49 	ppp 		[opt1] IPV6CP: Close event
                Aug 11 14:15:49 	ppp 		[opt1] IPV6CP: state change Opened --> Closing
                Aug 11 14:15:49 	ppp 		[opt1] IPV6CP: SendTerminateReq #8
                Aug 11 14:15:49 	ppp 		[opt1] IPV6CP: LayerDown
                Aug 11 14:15:50 	ppp 		[opt1] IFACE: Down event
                Aug 11 14:15:50 	ppp 		[opt1] IFACE: Rename interface pppoe1 to pppoe1
                Aug 11 14:15:50 	ppp 		[opt1] IPCP: Down event
                Aug 11 14:15:50 	ppp 		[opt1] IPCP: LayerFinish
                Aug 11 14:15:50 	ppp 		[opt1] IPCP: state change Closing --> Initial
                Aug 11 14:15:50 	ppp 		[opt1] IPV6CP: Down event
                Aug 11 14:15:50 	ppp 		[opt1] IPV6CP: LayerFinish
                Aug 11 14:15:50 	ppp 		[opt1] Bundle: No NCPs left. Closing links...
                Aug 11 14:15:50 	ppp 		[opt1] IPV6CP: state change Closing --> Initial
                Aug 11 14:15:50 	ppp 		[opt1_link0] LCP: SendTerminateAck #8
                Aug 11 14:15:50 	ppp 		[opt1_link0] LCP: LayerDown
                Aug 11 14:15:50 	ppp 		[opt1_link0] PPPoE: connection closed
                Aug 11 14:15:50 	ppp 		[opt1_link0] Link: DOWN event
                Aug 11 14:15:50 	ppp 		[opt1_link0] LCP: Down event
                Aug 11 14:15:50 	ppp 		[opt1_link0] LCP: state change Stopping --> Starting
                Aug 11 14:15:50 	ppp 		[opt1_link0] Link: reconnection attempt 1 in 3 seconds 
                
                1 Reply Last reply Reply Quote 0
                • M
                  mrvanity
                  last edited by

                  @kpa:

                  What part of the "Having two interfaces with the same gateway is not supported" you don't understand?

                  LOL!!!
                  You do realize that the part you have quoted is from December 2014, and this ("Having two interfaces with the same gateway" i mean) is a working feature of pfSense now.
                  I also guess you haven't read "In a 2.3 ALPHA Built 28 Dec 2015 snapshot, it worked like a charm."

                  Ok?
                  Are you ready to apologize for being rude in the first place?

                  1 Reply Last reply Reply Quote 0
                  • M
                    mrvanity
                    last edited by

                    Anyone having the same issue?
                    Thanx

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

                      I had the same issue in the past, and the only solution I found was statically routing my modems in different ip range.

                      1 Reply Last reply Reply Quote 0
                      • M
                        mrvanity
                        last edited by

                        Sorry for coming back at this one.
                        As mentioned above it worked very well at the 2.3 ALPHA Built 28 Dec 2015 snapshot.
                        In 2.3.2 is broken.

                        What files must i compare between between two versions to try and  find a solution?
                        My regards.

                        1 Reply Last reply Reply Quote 0
                        • N
                          netblues
                          last edited by

                          Just wondering about the state of this issue.
                          I currently have no means to test, but soon this will be changing.  :-\

                          1 Reply Last reply Reply Quote 0
                          • N
                            netblues
                            last edited by

                            I can safely verify that in 2.4.3-RELEASE-p1 (current stable) works as it should
                            One interface is left with the dynamicly selected monitor peer and the other
                            pings a stable ip inside the provider (in my case the cluster ip of the main dns stack)
                            If the provider changes her policy and blocks ping that would be an issue, but I think I can live with that. :)

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