Pass PPPoE /29 directly to another interface?
ajrg last edited by
I've had a quick chat in the IRC channel about this, but it's pretty quiet at the moment.
So… is it possible to use pfSense as a PPPoE authenticator, and then just have it pass the ISP supplied /29 out to another interface?
I'm trying to set up a HA failover pfSense pair, but the ISP only allows a single PPPoE session per customer. Thanks to their RADIUS setup, that PPPoE session can only be authenticated using the first available IP in the subnet, so effectively the PPPoE authenticator always has to take the address x.x.x.1/29. Not much use for HA/CARP.
I'm wondering if I can use a smaller pfSense box to do the PPPoE auth, and then have it pass the subnet to the HA pair out of another interface?
Could I achieve this by bridging WAN/PPPoE interface to OPT1?
Could I achieve this by disabling NAT and doing some routing setup to present the /29 on OPT1?
We do have another connection, so this wouldn't be introducing a single point of failure... the other connection is EFM, so it doesn't suffer this issue... It's just slow.
Just to be clear, this isn't an xDSL setup, so I can't use a bridging modem. It's a fibre connection that for whatever reason needs PPPoE authentication;
Fibre --> NTE (glorified media converter) --> Ethernet (but requires PPPoE to function)
I'm thinking something like this;
pfSense HA1 <-- Switch <-- pfSense PPPoE Auth <-- Ethernet <-- NTE <-- Fibre
pfSense HA2 <--
Is this plausible/feasible/stupid?
ajrg last edited by
Right, got this figured out and it's working brilliantly. For anyone else interested;
Bridging a PPPoE WAN to an OPT interface did not work for us. Although iftop did show attempted connections, no traffic passed. This may well be down to how our ISP handles traffic - I get the feeling they only allow a single MAC per subnet(!).
So, to get it working, we used three pfSense boxes. One to deal with PPPoE authentication and routing, the other two to as the HA cluster.
- Connect the PPPoE line to the WAN interface and configure it as normal. The ISP provides the first usable address in the subnet as a /29.
- Reconfigure the LAN interface to something suitably small (/29 will do) and stick it in it's own VLAN - we left room at the beginning of the subnet for the cluster.
- Add a static route from the LAN interface to the rest of the network, via the IP that the cluster's CARP VIP will use in that VLAN (so you can manage it from the main network).
- Assign another interface as OPT1 and configure it with the next available WAN IP as the gateway, and the next IP after that for the interface itself. Set the MTU to 1492.
- Connect something to OPT1 and set it to an available WAN IP using the pfSense interface OPT1 address as the gateway. Test it - you should be connected using a public IP.
- Disable all packet filtering/NAT on pfSense, and turn on all NIC offloading if your NICs support it. Turning on fast forwarding and device polling is also a good idea, if your NICs support it.
- Reboot pfSense and test again, it should still work. Disconnect your device from OPT1, and connect a switch to it instead.
- Connect both your pfSense cluster box WAN interfaces to the switch, and configure each with a WAN IP using the upstream pfSense box as the gateway.
- If you have a /29 subnet for your WAN, this will leave two WAN IPs to use for CARP VIPs. Follow the normal HA instructions from here.
One thing that's obvious is that you still have a single point of failure in the PPPoE authentication pfSense box, but that would also be true of using just one WAN connection.
We are using two pfSense boxes for the PPPoE stuff, to two different WAN connections, and an EFM connection. They all have /29 subnets, and all go through a stacked pair of switches. The connections from the pfSense PPPoE boxes use LACP so a single switch failure won't kill a connection, same for the WAN input to the main boxes. Each WAN is in it's own VLAN.
EFM is the only connection that only goes to one switch, but there isn't much we can do about that. If a switch dies, we can just re-patch it to the other.
The above is not the most efficient use of IP addresses, but it solves the problem we were looking to solve, with an ISP who have chosen to implement a frustrating setup.
EDIT: On the PPPoE box, you'll also need to;
- add an inbound rule to allow traffic destined for the OPT interface
- add an outbound rule to allow traffic not destined for LAN out of the OPT interface