PPPoE WAN Oddities
I am a UK resident and am, unfortunately, stuck using a PPPoA ADSL Service. My simplified configuration is as follows:
ISP > PPPoA to PPPoE DSL Modem > pfSense > Internal LAN
The long version is as follows:
ISP > Draytek Vigor 120 DSL Modem > Home Plug > *power line * > Home Plug > pfSense (Re-purposesed Desktop PC, 2 PHYS LAN ports) > Internal LAN (Switch)
For a very long time I have struggled with ongoing compatibility and connectivity issues but most recently for around 18 months my configuration has been stable. That is until 3 days ago. The core ISP provider did "Upgrades" and my configuration broke, and broke hard. It COULD be purely coincidental but my suspicion is changes to their core equipment/configs has broken my implementation, I am suspecting something RADIUS related but could be far off.
The failure is as follows:
PPPoA to PPPoE DSL Model get's line sync. Perfectly normal, stays connected, no stability or other issues.
pfSense detects the WAN port is physically up
pfSense starts the PPPoE process
PPP Authentication goes through as expected
IPCP Configuration Request is completed for IP Address, Pri/Sec DNS with addresses of 0.0.0.0
IPCP Configuration NAK is completed for the same and Client IP Address and Pri/Sec DNS IPs are established
pfSense Fails in the PPPoE process with the following
Log Entries in PPP:
ppp: [wan] 220.127.116.11 -> 0.0.0.0
ppp: [wan] IFACE: Adding IPv4 address to pppoe1 failed(IGNORING for now. This should be only for PPPoE friendly!): Destination address required
ppp: [wan] IFACE: Add route 0.0.0.0/0 0.0.0.0 failed: No such process
Log Entires in System:
php: rc.newwanip: rc.newwanip: Failed to update wan IP, restarting…
IPCP Termination Request is sent
PPPoE session is closed
pfSense starts the PPPoE process again
Now on the face of it it appears that no Gateway address is being established, a route is trying to be added with a 0.0.0.0 destination, pfSense is saying "Nope" and bailing out, the PPPoE Session is Closed and it tries again.
I have used a laptop connected directly to the DSL modem and dialled out a PPPoE session. It works but sometimes it bombs out with a generic windows error. Once connected however, there is no Gateway set. Historically my ISPs gateway would be set and all was fine. My old Netgear ADSL2 router dials the PPPoA session okay also but sets a gateway of 10.88.64.64....an unroutable local address.
Now this is my THEORY. pfSense is sensitive to lack of a gateway. I have done some extensive reading on the mdp process it uses to dial up a PPP session. I quote the specific section that helped me:
set ipcp ranges local/width remote/width
This command determines what IP addresses mpd will allow to be negotiated at the local and remote ends of the link. For each endpoint, we have a target address and a netmask width. The width determines how flexible we are, i.e., how close the actual negotiated address must be to the target address. A width of 32 means they must match exactly; a width of zero means any address is suitable. For example, 192.168.1.17/25 means that IP address 192.168.1.17 is desired, but any IP address in the range 192.168.1.0 through 192.168.1.128 is acceptable.
By convention, the local address may be 0.0.0.0 to request that the remote server assign us an IP address. Of course, for this to work the remote side must know a priori what our local IP address should be.
The remote address should not be 0.0.0.0. This is so if the peer requests 0.0.0.0, we have some address to give him. The width may of course be zero.
After some 12 hours I managed to band-aid edit /var/etc/mdp_wan.conf and get pfSense to establish a working WAN PPPoE connection.
I edited the range values in the mdp_wav.conf for the remote address. My pfsense default mdp_wan.conf is established as follows:
pppoeclient: create bundle static wan set bundle enable ipv6cp set iface name pppoe1 set iface route default set iface disable on-demand set iface idle 0 set iface enable tcpmssfix set iface up-script /usr/local/sbin/ppp-linkup set iface down-script /usr/local/sbin/ppp-linkdown set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns #log -bund -ccp -chat -iface -ipcp -lcp -link create link static wan_link0 pppoe set link action bundle wan set link disable multilink set link keep-alive 10 60 set link max-redial 0 set link disable chap pap set link accept chap pap eap set link disable incoming set link mtu 1492 set auth authname "user" set auth password pass set pppoe service "" set pppoe iface vr0 open
Note the set ipcp ranges 0.0.0.0/0 0.0.0.0/0
If I edit the file to reflect the following:
set ipcp ranges 0.0.0.0/0 10.88.64.64/0
Then pfSenses performs the following:
ppp: [wan] 5.40.z.z -> 10.88.64.64
Hey presto, internet.
Why 10.88.64.64? Who knows. It's what my PPPoA ADSL2 Router picked for the Gateway when it connected it worked, i copied it for pfSense testing. It's an unroutable uncontactable remote address, but it works.
So the question is. Has my ISP made changes to their RADIUS server/otherwise which means they are no longer specifying a remote-address for the Gateway Client Configuration. Or is this a pfSense bug that has seemingly manifested out of nowhere? I made zero configuration changes or Firmware updates between working and failing. Unfortunately I have no historical logs to see what Gateway was being used in the route prior to the failure.
Have been doing more testing today, trying to figure out WHAT process receives the ISP (WAN) Gateway address so I can step by step debug it. To see if anything is being sent to me.
I've established (I think) that the ISP gateway IP is not negotiated as part of the PPP IPCP phase as this only seems to set IP, Prin/Sec DNS. I have read the RFC documents for IPCP and Gateway IP is not part of the spec?
However, I have no idea WHAT sends the Gateway IP and over what protocol….I've monitored all packets on the WAN interface and not seen anything containing a gateway IP. Perhaps this is because my ISP is not sending it?
"Have been doing more testing today, trying to figure out WHAT process receives the ISP (WAN) Gateway address so I can step by step debug it."
Have you seen this?
I'm facing the same problem where PPPoE logon has been denied by TalkTalk (although it has worked over the last week but then TalkTalk started dropping the connections until today it would not come up) so I'm trying to figure out how I can packet sniff the communication between the router and phone socket to check the settings are correct.
I have noticed TalkTalk use TR069 which appears to be some sort of soap server setup perhaps to auto config the router, this is probably the same for all UK ISP's now considering the roll out of new routers which also support fibre and perhaps some of the GCHQ/Govt demands to record all net data as per the hastily agreed DRIP bill and the one before it, but without packet sniffing the communication I'm not getting very far myself plus older routers dont have TR069 AFAIK but I could be wrong. I know when I switch on the TR069 option it updates the router with the correct logon details instead of the default TalkTalk username and password, but keying in the correct username and password should not be an issue anyway.
DMZ is no good unfortunately as I cant get the WAN IP address to pfsense so it can update a domain name and the facilities in the router for dynamic dns doesnt work so I cant host email & web, putting aside the reverse DNS issue with some email servers not sending to email servers that do not reverse dns correctly.
I had also setup a bridged RaspberryPi to sniff the packets between the router in bridged mode and pfsense, but I also noticed this had been halted so when I get time later I will see what I can find from the TCPDumped packets.
What ISP are you on?
I would also say dont underestimate the ISP's capabilities.
Just an update after some investigations today.
On TalkTalk but might apply to other UK ADSL ISP's, the username and password issued is irrelevant!
I noticed in the huwei supplied firewall logs today the default username after a reset is firstname.lastname@example.org which was giving me net access when the router was working like one would normally expect, i not having changed the nas_0_38 from ppoa to bridge with tr069 switched off.
I then noticed I had keyed in the username wrong on pfsense, due to the linux device used to access pfsense having the wrong keyboard mapping so the " had swapped places with the @ so my login name was [phonenumber]"talktalk.net not [phonenumber]@talktalk.net. So having corrected it and still no joy, back to the drawing board, messed around the username & password on the huewei router and noticed I could use anything for a username like DoTalkTalkCheckThis@all with a random password and still got net access from the huewei router.
So I then went back to pfsense and reset the wan adaptor and set it to PPPoE with the correct username and password, set the MTU to 1400 to be on the safe side, removed some gateways so it only showed the WAN_PPOE and it all worked.
Now I also know I spoofed the WAN mac id the other day in a bid to see if I could attract some visitors who might be aware of the mac id I was using, I set it first to the talktalk youview box and with hindsight thats when the drop outs first started some hours later. I had also set it to the huewei mac id today and it didnt like that either.
Some further tests tonight and I can confirm it appears talktalk dont bother with usernames and passwords just the mac id, so like the mobile phone IMEI database which exists, the UK adsl net access is monitored/access given by the mac id it would see because everytime I used the router mac id in pfsense, no access, in fact everytime I spoofed the mac id in pfsense, no net access was given.
Its worth pointing out in part of the mac id is given out in the ARP packets so its probably possible to detect spoofed mac id's, which perhaps goes to show, coupled with things like google instant search which is obfusicated java script that can be used to detect typing speed and thus the unique typing patterns of an individual when combined with mac ids and other meta data as the spooks would call it, shows how deep and pervasive the big brother system really is!
Food for thought none the less when considering Edward Snowdens revelations, and the under hand tactics the politicians used to bring in various bits of legislation to "facilitate" this surveillance, whilst giving the biggest tech companies millions/billions to help them facilitate the big brother society.
Might be worth seeing if the nics hardware can be reprogrammed to get new mac ids to beat this system as we are all slowly financially cleansed from existence!