Trouble with Bell PPPoE
-
We are switching ISPs from a cable-based operator to Bell. Bell uses PPPoE which I have not worked with before. They provide a router that we had switched to bridge mode so that pfSense can handle everything.
From what I can find online, the process is pretty simple:
- create VLAN 35 on WAN
- set WAN to VLAN 35
- configure WAN to be PPPoE, provide username & password, set MTU to 1492.
After all this, it doesn't work. The logs have generic "can't connect" messages but nothing helpful. It never gets an IP address.
Anyone have any tips?
-
That should work. I would make sure the WAN shows correctly in Interfaces > Assignments. I expect it to be
PPPoE0(igb0.35)
for example.
Do the logs show any reply traffic in the connection attempt?
Try running a pcap on the parent NIC and make sure you see vlan 35 tagged traffic, both ways.You shouldn't need to set the MTU manually.
Steve
-
@stephenw10 Assignment is correct, WAN is set to PPPoE(vmx0.35).
Honestly there is a lot of conflicting info out there. The one thing I didn't immediately consider was MAC binding, but some others tried cloning the Bell router MAC and it didn't make a difference. We lose our old link by Sunday so I will end up spending the weekend in here until I get it working.
-
Mmm, MAC spoofing is not normally required for PPPoE but if you do need to do it assign vmx0 and set it there.
I assume you have seen the link work with Bell's router?
-
@stephenw10 Yes. Others have pointed out that you need to connect to the Bell router's gui and use an option to release the router. Unfortunately I've also read several posts from people who ended up not getting it working. It shouldn't be that hard.
-
@stephenw10 Sample log output:
Jul 28 10:38:12 ppp 77253 Multi-link PPP daemon for FreeBSD Jul 28 10:38:12 ppp 77253 process 77253 started, version 5.9 Jul 28 10:38:12 ppp 77253 web: web is not running Jul 28 10:38:12 ppp 77253 [wan] Bundle: Interface ng0 created Jul 28 10:38:12 ppp 77253 [wan_link0] Link: OPEN event Jul 28 10:38:12 ppp 77253 [wan_link0] LCP: Open event Jul 28 10:38:12 ppp 77253 [wan_link0] LCP: state change Initial --> Starting Jul 28 10:38:12 ppp 77253 [wan_link0] LCP: LayerStart Jul 28 10:38:12 ppp 77253 [wan_link0] PPPoE: Connecting to '' Jul 28 10:38:21 ppp 77253 [wan_link0] PPPoE connection timeout after 9 seconds Jul 28 10:38:21 ppp 77253 [wan_link0] Link: DOWN event Jul 28 10:38:21 ppp 77253 [wan_link0] LCP: Down event Jul 28 10:38:21 ppp 77253 [wan_link0] Link: reconnection attempt 1 in 4 seconds Jul 28 10:38:25 ppp 77253 [wan_link0] Link: reconnection attempt 1 Jul 28 10:38:25 ppp 77253 [wan_link0] PPPoE: Connecting to '' Jul 28 10:38:34 ppp 77253 [wan_link0] PPPoE connection timeout after 9 seconds Jul 28 10:38:34 ppp 77253 [wan_link0] Link: DOWN event Jul 28 10:38:34 ppp 77253 [wan_link0] LCP: Down event Jul 28 10:38:34 ppp 77253 [wan_link0] Link: reconnection attempt 2 in 3 seconds
-
Mmm, so nothing coming back at all then. I'd definitely be running a pcap on the parent interface and make sure the VLAN tagging it happening correctly.
-
@stephenw10 And it gets weirder. My test instance was virtual under ESXi, just like my regular pfSense instance. When I did a pcap, there as literally nothing. I wanted to rule out ESXi so I took an old Dell NX300 and spun up 2.6.0 CE. Configured it as per usual PPPoE and did another pcap. Again, nothing. Literally nothing. No packets or data whatsoever. The Dell is wired directly from bce0 to the LAN1 port on the Bell box so nothing is in between. I['m kind of baffled as to why there is nothing on WAN.
-
How did you run the pcap? It's easy to exclude vlan tagged traffic if you add any filters in the current gui page (improvements coming).
You should at least see the traffic pfSense is sending.
-
@stephenw10 I just made sure it was set to WAN and did not change anything else. Any/Any for Address/Protocol. Nothing else set. I verified with the ISP that the PPPoE login was correct and they tested it ok.
-
So literally 0 packets on vmx0? I would expect to see something there even if it wasn't trying to connect over PPPoE.
-
@stephenw10 So would I. The fact that this happens on a VM and on a physical server is very weird. The Packet Capture interface selector only shows WAN, LAN & localhost but not VLAN35. I assume this is normal? Regardless I would still expect to see some kind of traffic on the WAN. I don't really understand the internals of PPPoE. Does it use an APIPA address to talk to the headend to get its IP address, gateway, mask etc? If you have 5 minutes, I would be interested to see if this behaviour happens for you as well:
- Create vlan 35, prio 0
- Assign WAN to the vlan
- Set WAN for PPPoE
- Fill in some bogus creds
- Do a pcap and see if you get traffic
-
Ah, yeah you need to assign/enable vmx0 as an interface to pcap from it in the gui.
You can do it from the command line though.
PPPoE is not IP in the initial connection. You should still see packets though.
Steve
-
@stephenw10 Finally got it figured out.
-
When pfSense has gateway set to automatic, I still needed to force it to use the PPoE gateway even though it's the only gateway.
-
When your ISP tells you need to pass the traffic via vlan 35 on WAN, they're lying. No vlan configuration required.
-
When you ask your ISP to validate the credentials, check twice. First guy gave them to us initially, second guy said they were fine when I called to confirm them, I called again to validate and the third guy said the first letter is supposed to be a capital so I had the wrong creds the whole time.
Two days of my life wasted getting this working.
-
-
Urgh. Well glad you got up and running.
It's not unusual to see the PPPoE "modem" doing the VLAN tagging. That's exactly how my own WAN in setup here.
Steve
-
@stephenw10 I suspect that the modem is doing the vlan transparently so I just needed to configure the PPPoE login. Their support people didn't know that and were advising me to use vlan 35. Others also using Bell mentioned vlan 35, but I now know that's only in the context of connecting directly to the ONT via SPF with the modem totally out of the loop.
One pfSense glitch I noticed was that when I had Dial on Demand enabled (part of my patented Try Anything Panic-Mode Troubleshooting), you have to fill in an idle time. When every time you revisit that page thereafter, the idle time is blank and you can't save the page until you enter it again.
-
Hmm, I can't replicate that. In 22.05?
-
@stephenw10 No, 2.6.0
-
Mmm, can't replicate it there either.
When we see things like that it's almost always a browser plugin or auto-fill entering or removing values. Do you see it across different browsers?Steve
-
@stephenw10 Don't worry about it. It was Firefox with an adblocker but I hadn't seen that behaviour before with any other pfSense field. I'm not touching the pppoe config now that it's working.