Project

General

Profile

Actions

Bug #11629

open

PPPoE WAN IP address different than expected when set static by ISP

Added by Dan Rice 9 months ago. Updated 6 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
03/05/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:
All

Description

As per support ticket: #INC-77927

Hi, we've had this box and a previous one connecting to our service provider for the last 5 years or so and our PPPOE WAN connection has always been assigned the same IP from our block.

But we've noticed, maybe for the last few days, that our WAN interface is being assigned a different one from our block and so it's breaking some of our secure access as our public IP address is now different.

We upgraded the device to the lastest pfSense last Friday (26th Feb 2021) so i am not sure if it's coincided with that.

Looking in the system logs->System->General it shows our usual IP address being assigned via the PPP process so i am confused why a different one is being assigned in pfsense.

I have not included IP addresses or the status output from the router due to privacy, but can supply.

Actions #1

Updated by Jim Pingle 9 months ago

  • Subject changed from PPPOE IP address on WAN not what ISP is issuing to PPPoE WAN IP address different than expected when set static by ISP
  • Category changed from Administrivia to Interfaces
  • Status changed from New to Feedback
  • Private changed from Yes to No

We will need a lot more information here since it isn't happening to others that we're aware of yet.

Things like PPPoE settings, connection logs, ifconfig output, and what the expected values are vs what you're observing. If you have privacy concerns you can submit the information using the support issue you have open already, but the bug entry itself here won't be private.

It could be a difference in the PPPoE configuration as generated before vs now which is making the ISP see the client as different somehow, which could end up being something you could fix with settings, but without more data it's difficult to speculate.

Actions #2

Updated by Dan Rice 9 months ago

Our IP block and router status output is aleady attached to the support ticket. I will also attached the other info to the support ticket.

Actions #3

Updated by Dan Rice 9 months ago

Requested info has been added to the support ticket.

Actions #4

Updated by Marcos Mendoza 9 months ago

It seems like the IPs are assigned to the interface in ascending order no matter what pppoe server gives

(reverse order)

Mar 5 14:23:49     ppp     62519     [wan] IFACE: Rename interface ng0 to pppoe2
Mar 5 14:23:49     ppp     62519     [wan] IFACE: Up event
Mar 5 14:23:49     ppp     62519     [wan] 1.2.3.222 -> 6.7.8.23
Mar 5 14:23:49     ppp     62519     [wan] IPCP: LayerUp
Mar 5 14:23:49     ppp     62519     [wan] IPCP: state change Ack-Sent --> Opened
Mar 5 14:23:49     ppp     62519     [wan] IPADDR 1.2.3.222
Mar 5 14:23:49     ppp     62519     [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent)
Mar 5 14:23:49     ppp     62519     [wan] IPADDR 1.2.3.222
Mar 5 14:23:49     ppp     62519     [wan] IPCP: SendConfigReq #3
Mar 5 14:23:49     ppp     62519     [wan] 1.2.3.222 is OK
Mar 5 14:23:49     ppp     62519     [wan] IPADDR 1.2.3.222

pppoe2: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
 description: WAN
 inet6 fe80::2e0:edff:febe:ef64%pppoe2 prefixlen 64 scopeid 0xe
 inet 1.2.3.217 --> 6.7.8.24 netmask 0xffffffff
 inet 1.2.3.218 --> 6.7.8.24 netmask 0xffffffff
 inet 1.2.3.219 --> 6.7.8.24 netmask 0xffffffff
 inet 1.2.3.220 --> 6.7.8.24 netmask 0xffffffff
 inet 1.2.3.221 --> 6.7.8.24 netmask 0xffffffff
 inet 1.2.3.222 --> 6.7.8.24 netmask 0xffffffff
 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Actions #5

Updated by Jim Pingle 9 months ago

Perhaps this is another variation of #11545 and not a unique issue

Actions #6

Updated by Viktor Gurov 7 months ago

Jim Pingle wrote:

Perhaps this is another variation of #11545 and not a unique issue

This could be an another issue - if the PPPoE Server changes the IP address pool and `/usr/local/sbin/ppp-linkup` doesn't start, you'll see the updated IP address at the bottom.

Actions #7

Updated by Daniel van der Wal 6 months ago

Jim Pingle wrote:

We will need a lot more information here since it isn't happening to others that we're aware of yet.

We can confirm we have the same issue. After a ppp reconnect (seems to happen once a week, I guess triggered by the ISP) the wrong IP is assigned here the .76 instead of the .73 (First IP in our public IP block)

We do have 2 virtual IP's defined .76 and .77. The selected IP seems random as it's not the last or lowest or highest in our range and virtual ip list...

Are there any possible workarounds? At the moment this is a big show stopper....
Could we prevent the rc.newwanip from setting a new IP that is the wrong one? We end up with no WAN and the wrong IP on IPSEC and OpenVPN services...

If it would help we can share more logging information...

May 28 01:54:41 php-fpm 54474 /rc.newwanip: Forcefully reloading IPsec
May 28 01:54:38 php-fpm 54474 /rc.newwanip: Default gateway setting Interface WAN_PPPOE Gateway as default.
May 28 01:54:37 php-fpm 54474 /rc.newwanip: rc.newwanip: on (IP address: xx.xx.xxx.76) (interface: WAN[wan]) (real interface: pppoe0).
May 28 01:54:37 php-fpm 54474 /rc.newwanip: rc.newwanip: Info: starting on pppoe0.
May 28 01:54:36 ppp 14153 [wan] IFACE: Rename interface ng0 to pppoe0
May 28 01:54:36 ppp 14153 [wan] IFACE: Up event
May 28 01:54:36 check_reload_status 390 rc.newwanip starting pppoe0
May 28 01:54:36 ppp 14153 [wan] xx.xx.xxx.73 > xxx.x.xxx.196
May 28 01:54:36 ppp 14153 [wan] IPCP: LayerUp
May 28 01:54:36 ppp 14153 [wan] IPCP: state change Ack-Sent -
> Opened
May 28 01:54:36 ppp 14153 [wan] IPADDR xx.xx.xxx.73
May 28 01:54:36 ppp 14153 [wan] IPCP: rec'd Configure Ack #11 (Ack-Sent)
May 28 01:54:36 ppp 14153 [wan] IPADDR xx.xx.xxx.73
May 28 01:54:36 ppp 14153 [wan] IPCP: SendConfigReq #11
May 28 01:54:36 ppp 14153 [wan] xx.xx.xxx.73 is OK
May 28 01:54:36 ppp 14153 [wan] IPADDR xx.xx.xxx.73
May 28 01:54:36 ppp 14153 [wan] IPCP: rec'd Configure Nak #10 (Ack-Sent)
May 28 01:54:36 ppp 14153 [wan] IPADDR 0.0.0.0
May 28 01:54:36 ppp 14153 [wan] IPCP: SendConfigReq #10

Actions #8

Updated by Viktor Gurov 6 months ago

workaround:

You could use VIPs from your /29 for all the VPNs/services. If clients are using an FQDN you could just update the DNS to point at the VIP.

If that's not possible as a workaround try adding xx.xx.xxx.73 as an IP Alias. It will then be selectable as the server IP directly rather than 'WAN'.

Actions

Also available in: Atom PDF