4. Multi WAN with same gateway IP intereferes with balancing

Multi WAN with same gateway IP intereferes with balancing

  • M

    Hi

    I have two ADSL modems at home connected to a pfSense machine and I use pfSense to log in to the ISP with PPPoE. Sometimes the WAN interfaces get the same gateway IP address. HOME_WAN interface connects to HOME_WAN_PPPOE gateway and OFFICE_WAN interface connects to DRAYTEK gateway. This causes pfSense to mark one of the gateways (the 2nd one to connect) with a status of Unknown like so:

    The external IPs of the interfaces are correct and the modems function fine when I force traffic down the HOME_WAN interface, but when they are balanced using gateway groups, all the traffic gets sent down OFFICE_WAN and not HOME_WAN. Any ideas on how to fix this? At the moment I’m having to split the gateways manually between sets of PCs which brings it’s own problems because PC usage patterns vary.

    Thanks for any tips…

    0
  • R

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

    0
  • Rebel Alliance Developer Netgate

    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.

    0
  • M

    @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.

    0
  • M

    @rcampbell:

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

    There you go.

    0
  • N

    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

    0
  • R

    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


    0
  • N

    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

    0
  • M

    @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
    0
  • M

    @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?

    0
  • M

    Anyone having the same issue?
    Thanx

    0
  • S

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

    0
  • M

    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.

    0
  • N

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

    0
  • N

    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. 🙂

    0
 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy