PPPoE with private gateway IP conflicts with LAN
-
Hello everyone.
I connect with my ISP via PPPoE (
Passthrough
), for the last couple of years it everything was rock solid,
until ISP decided without notice to change their gateway IP from a public one (80.x.x.x
) to a private one (10.10.10.1)
.The issue here is that my LAN interface uses the same IP (
10.10.10.1
), and by the looks of it, WAN has trouble staying up for that reason.Below is a snippet of the ppp logs that keeps repeating (each time with a new IPv4 public IP).
As soon as I use their "generic" credentialsmyisp/myisp
PPPoE link stays up because the gateway IP there is10.106.108.100
but I can't keep this connection
as it's behindCGN
.In my WAN interface I have unchecked the "
Block private networks and loopback addresses
" checkbox.ISP won't change their gateway IP, they even play the "we haven't changed anything" card when you call them.
(But I know that this change happens to every customer that now connects to a Nokia 7750 gateway, and to none customer that connects to a Cisco ASR9,
based on the hostnames on the traceroute)Apart from changing my LAN, is there anything I can do?
Thanks anyone taking the time read this.
Jul 11 10:07:25 ppp 94406 [wan] IFACE: Down event Jul 11 10:07:25 ppp 94406 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address Jul 11 10:07:25 ppp 94406 [wan] IPCP: LayerDown Jul 11 10:07:25 ppp 94406 [wan] IPCP: SendTerminateReq #4 Jul 11 10:07:25 ppp 94406 [wan] IPCP: state change Opened --> Closing Jul 11 10:07:25 ppp 94406 [wan] IPCP: Close event Jul 11 10:07:25 ppp 94406 [wan] IFACE: Close event Jul 11 10:07:25 ppp 94406 caught fatal signal TERM Jul 11 10:07:25 ppp 20200 waiting for process 94406 to die... Jul 11 10:07:25 ppp 20200 process 20200 started, version 5.9 Jul 11 10:07:25 ppp 20200 Multi-link PPP daemon for FreeBSD Jul 11 10:07:23 ppp 94406 [wan] IFACE: Add description "WAN" Jul 11 10:07:23 ppp 94406 [wan] IFACE: Rename interface ng0 to pppoe0 Jul 11 10:07:23 ppp 94406 [wan] IFACE: Up event Jul 11 10:07:23 ppp 94406 [wan] IFACE: Adding IPv4 address to pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): File exists Jul 11 10:07:23 ppp 94406 [wan] 94.70.35.191 -> 10.10.10.1 Jul 11 10:07:23 ppp 94406 [wan] IPCP: LayerUp Jul 11 10:07:23 ppp 94406 [wan] IPCP: state change Ack-Sent --> Opened Jul 11 10:07:23 ppp 94406 [wan] IPADDR 94.70.35.191 Jul 11 10:07:23 ppp 94406 [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent) Jul 11 10:07:23 ppp 94406 [wan] IPADDR 94.70.35.191 Jul 11 10:07:23 ppp 94406 [wan] IPCP: SendConfigReq #3 Jul 11 10:07:23 ppp 94406 [wan] 94.70.35.191 is OK Jul 11 10:07:23 ppp 94406 [wan] IPADDR 94.70.35.191 Jul 11 10:07:23 ppp 94406 [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent) Jul 11 10:07:23 ppp 94406 [wan] IPADDR 0.0.0.0 Jul 11 10:07:23 ppp 94406 [wan] IPCP: SendConfigReq #2 Jul 11 10:07:23 ppp 94406 [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 11 10:07:23 ppp 94406 [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent) Jul 11 10:07:23 ppp 94406 [wan_link0] rec'd unexpected protocol IPV6CP, rejecting Jul 11 10:07:23 ppp 94406 [wan] IPCP: state change Req-Sent --> Ack-Sent Jul 11 10:07:23 ppp 94406 [wan] IPADDR 10.10.10.1 Jul 11 10:07:23 ppp 94406 [wan] IPCP: SendConfigAck #22 Jul 11 10:07:23 ppp 94406 [wan] 10.10.10.1 is OK Jul 11 10:07:23 ppp 94406 [wan] IPADDR 10.10.10.1 Jul 11 10:07:23 ppp 94406 [wan] IPCP: rec'd Configure Request #22 (Req-Sent) Jul 11 10:07:23 ppp 94406 [wan_link0] rec'd unexpected protocol IPV6CP, rejecting Jul 11 10:07:23 ppp 94406 [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 11 10:07:23 ppp 94406 [wan] IPADDR 0.0.0.0 Jul 11 10:07:23 ppp 94406 [wan] IPCP: SendConfigReq #1 Jul 11 10:07:23 ppp 94406 [wan] IPCP: state change Starting --> Req-Sent Jul 11 10:07:23 ppp 94406 [wan] IPCP: Up event Jul 11 10:07:23 ppp 94406 [wan] IPCP: LayerStart Jul 11 10:07:23 ppp 94406 [wan] IPCP: state change Initial --> Starting Jul 11 10:07:23 ppp 94406 [wan] IPCP: Open event Jul 11 10:07:23 ppp 94406 [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps Jul 11 10:07:23 ppp 94406 [wan_link0] Link: Join bundle "wan" Jul 11 10:07:23 ppp 94406 [wan_link0] Link: Matched action 'bundle "wan" ""' Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: authorization successful Jul 11 10:07:23 ppp 94406 [wan_link0] MESG: Login ok Jul 11 10:07:23 ppp 94406 [wan_link0] PAP: rec'd ACK #1 len: 13 Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: LayerUp Jul 11 10:07:23 ppp 94406 [wan_link0] PAP: sending REQUEST #1 len: 34 Jul 11 10:07:23 ppp 94406 [wan_link0] PAP: using authname "myredacteduser@isp.tld" Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: auth: peer wants PAP, I want nothing Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: state change Ack-Rcvd --> Opened Jul 11 10:07:23 ppp 94406 [wan_link0] MAGICNUM 0x3ada4703 Jul 11 10:07:23 ppp 94406 [wan_link0] AUTHPROTO PAP Jul 11 10:07:23 ppp 94406 [wan_link0] MRU 1514 Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: SendConfigAck #217 Jul 11 10:07:23 ppp 94406 [wan_link0] MAGICNUM 0x3ada4703 Jul 11 10:07:23 ppp 94406 [wan_link0] AUTHPROTO PAP Jul 11 10:07:23 ppp 94406 [wan_link0] MRU 1514 Jul 11 10:07:23 ppp 94406 [wan_link0] LCP: rec'd Configure Request #217 (Ack-Rcvd)
-
@StavrosMadK
Call the ISP and tell him that he is a f...g idiot. Private network ranges are meant for private use in local networks. He can use any IP for the PPP gateway apart from these. Maybe a CG-NAT.As far as I know, there is no option to reject an IP in PPPoE.
-
@StavrosMadK said in PPPoE with private gateway IP conflicts with LAN:
The issue here is that my LAN interface uses the same IP (10.10.10.1)
So you are not using pfBlockerng, as it also needs that IP/network that RFC1918 for its own usage.
Lucky you ^^But true : first, do what @viragomann said : make sure your ISP gets a copy of your opinion and thought. Or just, be gentile, and use you consumer power : say goodbye and get another one.
Usng n RFC1918 as a WAN IP : you'll most probably lost your access your pfSense with, for example, a VPN access, when you're outside.Then, for the time being : stop using 10.10.10.1/24 on your LA(s) - use now, for example, 10.10.11.1/24
Don't forget so update the settings on the DHCP server page for that interface.Btw : pfSense LAN was default 192.168.1.1/24
-
@viragomann said in PPPoE with private gateway IP conflicts with LAN:
@StavrosMadK
Call the ISP and tell him that he is a f...g idiot. Private network ranges are meant for private use in local networks. He can use any IP for the PPP gateway apart from these. Maybe a CG-NAT.As far as I know, there is no option to reject an IP in PPPoE.
Yea I have contacted "Support" line that "escalated" it but resolution was: We approved a "change equipment' order, go to the nearest store. (Its not the equipment, as I've tried 3 others just for the lolz).
Second time was escalated, resolution was a hard reset.As there was a few other people that had issues, we sent an email to a contact inside the ISP, which was probably just thrown in the trashcan as there was no answer.
I would happily changed ISP, if there was other option. Well other option exists but is 20mbps (instead of 200mpbs I have now.)
This ISP is considered Top Tier in the country (sad).Well there goes my weekend, migrating to new LAN IP and updating everything in the network -.-
-
@Gertjan said in PPPoE with private gateway IP conflicts with LAN:
So you are not using pfBlockerng, as it also needs that IP/network that RFC1918 for its own usage.
Lucky you ^^Whats the point if you can't reach "internet" at all? :D haha
-
Send this to your ISP https://datatracker.ietf.org/doc/html/rfc6598
-Rico
-
@Gertjan said in PPPoE with private gateway IP conflicts with LAN:
So you are not using pfBlockerng, as it also needs that IP/network that RFC1918 for its own usage.
That is just the default, you can change the pfBlocker Virtual IP to any unused RFC1918 you like.
-Rico
-
I've called again, this time agent was more willing to "write down" more details. Hopefully this time will escalate to someone that will
give a f**ckcare.With those ISP's is nearly impossible to reach someone besides the agents that follows the "is online LED flashing?" script...
-
@Rico said in PPPoE with private gateway IP conflicts with LAN:
That is just the default, you can change the pfBlocker Virtual IP to any unused RFC1918 you like.
That is the issue here.
192.168.1.1/24 is the default pfSense LAN. @StavrosMadK had reasons to change to that.
The thing is : he has forgotten he can change it again.
And "can" now became a "must", because WAN network == LAN network.@StavrosMadK said in PPPoE with private gateway IP conflicts with LAN:
Hopefully this time will escalate
Your ISP, mine, all the others, they have the same problem : they've bought boatloads of IPv4 in the good old days. These days, thee IPv4 are worth a fortune.
They can't give every customer an IPv4 anymore. So, they map more and more clients to RFC1918 (CGNAT ?) as that will give them a solution.
You want a real IPv4 ? You'll have to $$ ^^Very strange they didn't warn you about this.
If you had some ports NAtted, or were using the classic OpenVPN to connect remotley to your home, you have lost that functionality now. -
@Gertjan said in PPPoE with private gateway IP conflicts with LAN:
The thing is : he has forgotten he can change it again.
I didn't forgot that :) But wanted to avoid that as it was a pain to do and I would like to have avoided that. (finished the change last night).
@Gertjan said in PPPoE with private gateway IP conflicts with LAN:
Your ISP, mine, all the others, they have the same problem : they've bought boatloads of IPv4 in the good old days. These days, thee IPv4 are worth a fortune.
They can't give every customer an IPv4 anymore. So, they map more and more clients to RFC1918 (CGNAT ?) as that will give them a solution.The thing is, they STILL give a public IPv4 address. Their gateway is (and was) the issue..
You want a real IPv4 ? You'll have to $$ ^^
They have you pay for static (only for business plans). Which also will suffer from the above issue when the rollout is complete (and they use a network 10.10.10.0/x