Alternatives to PPPOA?



  • Hi,

    Until recently I've run pfsense and webservers sweetly from behind a cable modem by assigning the wan a static ip/gateway ip/dns servers (general settings).

    Sadly, I've had to move these boxes to a new location with adsl and pppoa.

    I've unsuccessfully tried connecting with the same configuaration (as the working cable setup), different wan static ip/gateway/dns info provided by my new isp, and my adsl modem in bridge mode.

    From testing and conversation with staff at the isp, it appears I'm only given the static ip once the adsl modem authenticates my account via pppoa.

    I really don't want to resort to connecting via the modem, for example in half-bridge mode (defeats original reason for using pfsense), and I can't use pppoe/dhcp/other connection methods via pfsense.

    (I've read posts where users had the luck of pppoe working in this situation, but it won't work for me.)

    My setup is very simple:

    isp –> modem(bridged) --> (wan)pfsense(lan) --> switch -- > servers

    Anyone know if pppoa via pfsense may be possible somehow eg a patch I don't know of?

    Am I doing anything that is obviously wrong (i'm a noob =)

    (Thanks to everyone who has and is contributing to this great software!)



  • Use the PPoE and put your PPoA settings in there, I have PPoA connection here in the UK, a while ago I tested it and it worked fine.

    I have a completly different setup now, although still with same isp/connection type.

    Give it a go, it should work!

    Slam



  • I have use pppoe and static addressing with pfsense. I works both ways no issues.
    RC



  • Thanks  :)

    I've previously tried using my pppoa authentication settings in the pppoe fields… but without connection success.

    After reading your posts, I tried again - but with no luck, this being confirmed by both the state table of pfsense and a phone call to my ISP.

    My only guesses are that pppoe isn't possible with my ISP (as they state) or I haven't bridged my modem correctly.

    Any other suggestions?



  • Does anyone know if pfsense 1.3 will have pppoa support?

    I've found that a ticket was created for this as early as 2005:

    http://cvstrac.pfsense.com/tktview?tn=274

    Perhaps, using adsl, I'm in a minority here?

    (If my office had cable installed, I'd switch to it immediately, and my issue would be solved.)

    Thanks



  • I have heard many people can work just fine with PPPoA on pfSense..  Search the forum.



  • If you read my posts…

    I have tried using the pppoe option (several times).

    And prior to this I did search the forums here thoroughly, and found users who had either reported:

    a) uninterrupted success with pppoe even when their isp states they only support pppoa;
    b) success then failure: http://forum.pfsense.org/index.php?topic=3429.msg29352
    c) no success at all (like me).

    I can post all the links of mixed results, including confusion re support of pppoa in pfsense, if you like?

    I don't want to drag this issue on... but it appears from reading previous posts, thoroughly, that just 'giving pppoe a try' (as has been suggested in previous posts on this subject)... doesn't work for some users.

    I'm very appreciative of the time that is donated to build and improve this product, and the time people take to reply to posts in this forum, but a definitive answer to the subject of whether 1.3 (or later) will have pppoa support, would determine whether I should continue trying to use pfsense or not at this time.

    Thanks



  • Can you try after selecting the type of wan as pppoe modifying this in config.xml MANUALLY adding this setting.
    find the <interfaces>tag then <wan>under <pppoe>add a tag <pppoetype>pppoa</pppoetype>

    And report back!</pppoe></wan></interfaces>



  • Thanks ermal,

    I hope I have followed your advice correctly.

    Below is what the (hopefully) relevant bit of my config.xml file looks like after adding the pppoetype tag:

    <pppoe><pppoetype>pppoa</pppoetype>
    <username>xxxxx@xxxxxxx.com</username>
    <password>xxxxxxxxxxxxxxxxx</password></pppoe>

    Contrary to your advice, the above pppoe tag is not enveloped within the wan tag (or interface tag), but sits outside and below as follows:

    <wan><if>vr0</if>
    <mtu><media><mediaopt><bandwidth>100</bandwidth>
    <bandwidthtype>Mb</bandwidthtype>
    <spoofmac><disableftpproxy><ipaddr>pppoe</ipaddr></disableftpproxy></spoofmac></mediaopt></media></mtu></wan>

    <staticroutes><pppoe><pppoetype>pppoa</pppoetype>
    <username>xxxxx@xxxxxxx.com</username>
    <password>xxxxxxxxxxxxxxxxx</password></pppoe>

    Unfortunately, the above edit hasn't fixed the connection problem.

    In the Interface Status page, the WAN status is 'up' but pppoe shows no connection, even after I press the 'Connect' button.

    I hope the above info helps diagnose the issue here.

    I am using 1.2 - at least last time I checked.

    Many thanks!</staticroutes>



  • Has anyone else tried the edit ermal suggested (see 2 posts back)?

    If so, have I done it correctly (see last post)?

    I've tried placing his code within the wan tags too, but without any connection success.

    Sorry to sound so impatient - but I was about to launch a web service via a cable connection, and moving to adsl and being offline has wasted a lot of precious time.

    I'm waiting to hear back from an ISP as to whether we can get the local fibre to my office, but even if they can do this, it may take nearly a month before being installed - so I'm stuck with adsl for a while.

    thanks

    PS When I have more time, I hope to contribute a package of my own design to this project, so I hope I don't come across an impatient leech! =)



  • I will give you a patch soon to make it work propperly.

    Just be patient :).



  • Thanks so much ermal! (This is COMMUNITY! blush)

    If your patch works, I may raid the startup jar here, and donate to you/pfsense!!!

    In the interim, here's a few ideas to show my thanks (tho' they've probably been posted before or are under my nose in the site/software somewhere):

    1. www.pfsense.com/configs/ - where config.xml files are shared like templates.

    A user needs a particular network setup, but is unsure if they have configured the basics correctly in pfsense, so they:
     a) visit the above page,
     b) browse/search for a config file that matches/closest to their network requirements,
     c) and download to their PC/laptop/device to upload to their pfsense box.

    Configs would be listed with the format of standard network diagram/text description/numeric stat's (eg ip ranges)/etc (number of users downloaded/rating/case studies/whatever).

    2. Config.xml file download facility in pfsense – like for packages.

    A user could:
    a) browse the same (as 1) config file sharing library within pfsense itself - and download config files as they can packages now - with the facility to activate one.
     b) upload config files from within pfsense to the same library for sharing successful, experimental (for research), and problematic (for diagnosis) setups.
    c) possibly choose from a few rudimentary config files included locally with initial pfsense setups, allowing users to choose from them immediately (and before having a net connection) - like the convenience of templates.

    3. AJAX/DHTML Network Builder Page in pfSense.

    A user could create networks, firewall rules, etc, on a single interactive page within pfsense… get design feedback based on standard networking rules, and ultimately share the resulting config files as per 1 and 2 above.
    The dashboard page coming in 1.3 (and available as a package for 1.2) demonstrates the possibility of this.

    There would have to be some security checks built into sharing config files, for example:
     a) a preview system in pfsense for users to check for personal info before sending;
     b) an automated checker/swapper in preview stage and in the web repository;
     c) a standard notation for dummy data so users could easily swap with their own settings.
    d) and a bunch of stuff I haven't thought of but smarter/more learned pfsense users would suggest (this applies to all the suggested ideas above.=)

    Just some thoughts for future features. 3 may be far off, but 1 and 2 could be feasible in near-term, and help your community grow, learn, and improve pfsense.

    Now that's off my chest... I have one more long-winded thing to write:

    This software and community kicks butt! I'm happy I didn't choose the '''community edition''' alternatives to pfsense. With people like ermal (and previous posters here) on board, pfsense has a friendly, fun, and market leading future!

    The team here eagerly awaits your patch... (and is looking for the jar!:)

    Thanks ermal!!!



  • Hi ermal,

    I just got nudged to the Post a Bounty forum by one of my team who is less patient than me.

    Honestly - I didn't even see that forum (though it's listed right below this one)!

    When I first posted, I thought a patch may have been available via the main site somewhere and I had overlooked it - I didn't expect someone to volunteer to write one to solve our (and others) pppoa problems.

    The coin-jar is pretty small here and shrinking… as we aren't on our way to making any money by being offline.

    But if posting a bounty for this patch, would free you up to finish and release it for all pfsense users to benefit, my team would certainly consider it.

    We would have to weigh it versus the cost of fibre being installed to the office, but if it were timely, we could come to some arrangement, and I'm sure others with the same problem would be happy to contribute.

    What time frame do you think your patch would be available, and where on the site would we (and rest of community) download it?

    I'm sorry if I seem impatient.

    We very much appreciate your offer, and eagerly await news of your progress.

    Thanks



  • Hi ermal,

    I've got the whole team on my back to order fiber tomorrow - instead of waiting for a PPPoA patch.

    Even if I find the dollars for fibre, installing it will take the ISP some weeks, and co-location/hosting isn't an option for us.

    So, I'd like to get pfsense going with pppoa, if poss, in the short-term - even if we get fibre later. (And with a patch, we are likely to keep adsl for redundancy using multi-wan.) Others on this board may benefit from your patch for a lot longer - if they are stuck with adsl.

    And we'll be able to launch our first apps! :-)

    I really appreciate your offer and help, and I'm sorry if you feel a lot of pressure. We will consider offering a bounty - if you can give us a timeframe.

    How's the patch coming along?

    If it isn't - because of other commitments, please drop me a post.

    I'll understand - you were generous enough to suggest editing the config file, and everyone here thought that was really cool!

    Cheers!



  • It is just a patch backported from the HEAD of pfSense.

    I have not tried it but if you have success report back.

    The patch is attached and is against 1.2.

    pppoa_diff.txt



  • Hi,

    Great to hear there is a patch for PPPoA! In New Zealand our nationwide Telecom ADSL network only supports PPPoA, (with the exception of Telstraclear’s small metro network which uses PPPoE).

    I'm running pfSense 1.2 embedded, my question is how do I apply this patch. I have downloaded pppoa_diff.txt, do I manually have to edit the files specified in pppoa_diff.txt, or is there another way?  ???

    Sorry I'm pretty green when it comes to this sort of thing, but I am really excited about getting PPPoA working!  :)

    Any help or pointers would be appreciated?



  • I can't possibly see how Ermal's patch can work - it appears to be setting up PPTP ("set link type pptp"), not PPPoA. There are some ISPs that deliver links over PPTP, so it's a worthwhile option to have, but it's not PPPoA! Further evidence that this is not PPPoA is that there's no facility added to the user interface to enter the VPI, VCI and encapsulation type, all of which are essential for a PPPoA connection.

    You can't bridge PPPoA (PPP over ATM AAL5) to Ethernet and pick it up at the other end as PPPoE. In PPPoA, PPP is overlaid on ATM AAL5; the PPP is inside ATM frames. You need an ATM stack to recover the PPP frames. All the details are in RFC 2364.

    PPPoE is the version of PPP designed to be carried over Ethernet. You could come up with a schema to encapsulate PPPoA in Ethernet frames, carry it over Ethernet to another device and unencapsulate it - but you'd still need an ATM stack to recover the PPP frames.

    Those that say "just use PPPoE" are on ISPs that allow you to use PPPoE as an alternative as PPPoA - this includes all IPstream based ISPs in the UK, where BT Openworld specify PPPoA as the preferred connection type, though PPPoE will work in almost every case and is now officially documented in the BT SINs. ISPs can disable the ability to use PPPoE on their RADIUS servers; I don't know of any that do.

    However, there are four possible ways to deal with this situation. This message comes to you over a PPPoA connection via pfSense!

    If you have a single IP address PPPoA account, find an ADSL router that offers PPP "half bridge" and support PPPoA (check Westell and Thomson Speedtouch manuals for this support; Conexant chipset routers also tend to offer this but some Conexant chipset routers are bargain basement junk). In this case, the router terminates the PPPoA and offers the WAN IP address on the LAN side via DHCP. You set pfSense to DHCP on the WAN side (or static IP if you have a static IP from the ISP - though beware of the situation where the gateway address changes from connection to connection as is the case on the BT IPstream platform - you need to use DHCP even with static IP in that case to pick up the correct gateway address).

    If you have a PPPoA account with multiple IP addresses, find an ADSL router that allows no-NAT routing and the firewall to be disabled - ZyXEL Prestige P660H series are suitable; I'm using a P660H-61.

    Leave the WAN side of the router on dynamic IP - it will pick up the correct details from your ISP (again, on the UK BT IPstream platform, the gateway address changes from connection to connection). Your ISP assigned gateway address must not change from connection to connection - though that's usually no problem, as it's typically one of the addresses in your netblock.

    The router takes your ISP assigned gateway address on the WAN side - you configure the LAN side of the router to that same address, and set the netmask according to your netblock (you can subnet the block on a ZyXEL Prestige if you wish; use static routes on the Prestige's telnet menu interface to route these subnet blocks).

    You set pfSense's WAN screen to another IP address in your netblock, the netmask the same as the netblock you configured on the LAN side of the router and the gateway address to be the router's LAN address. Proxy ARP in the virtual IP screens of pfSense will allow you to use the other addresses in your netblock.

    This approach costs you one address more than terminating the connection directly on pfSense. If you do use a ZyXEL router, you probably need to install WAN packet filters on TCP/UDP ports 53, 161 and 162 to block WAN access to the recursive DNS server and SNMP features of the router (dumb design by ZyXEL, but the filter isn't hard to set up). I can write a 'how to' if necessary - indeed, if people are interested in a 'how to' on this second option using a ZyXEL P660 series router, I'll write one when I have some time.

    The third option is to terminate the WAN connection directly on your main router - for example, using a PCI ADSL card. Unfortunately this really isn't possible in pfSense; the ATM code in FreeBSD has become rather moribund, and the supply of DSL cards (and ATM NICs) is drying up.

    The fourth way is to use a router that breaks the PPPoA encapsulation and re-encapsulates the PPP as PPPoE (this is not just encapsulating PPPoA as Ethernet - the PPPoA is unencapsulated to PPP, then re-encapsulated as PPPoE). 3Com used to make an ADSL router that did this - but it's long discontinued and I believe it wasn't very reliable.

    For all the hassles of PPPoA, it can offer lower overheads on ATM connections, especially in the VC-mux variant (one reason why BT Openworld specify PPPoA as their preferred connection type for IPstream), also it allows a 1500 byte WAN MTU whereas 1492 is the maximum MTU for Ethernet because of the 8 byte PPPoE header.



  • Hi,

    The ADSL router I'm trying to use is a SMC7904BRA2, it supports RFC 1483 Bridging, RFC 1483 Routing, IP over RFC 1483 Bridged, PPPoA and PPPoE.

    PPPoE is out as it’s not supported in NZ. I’ve successfully used PPPoA half bridge before on other routers, but this one doesn’t seem to support it.

    Hence why I would like to use PPPoA bridged. As a side note, when I select the configuration for RFC 1483 Bridged/Routing/IP extension, I can set the encapsulation (VM MUX) and VPI/VCI (0/100) in the routers configuration, so I assume this wouldn’t have to be set in the pfSense configuration?



  • As a side note you can always DMZ an ip to pfSense. That's what i had to do.



  • RFC 1483 bridged is not RFC 2364 PPPoA. RFC 1483 defines various encapsulation methods for ATM AAL5, but not a PPP one - that's the PPPoA that came along in RFC 2364. On many ISPs the RFC 1483 methods, which are essentially IP on ATM AAL5, are being obsoleted and replaced by PPPoA for greater flexibility in the ISP network.

    You can't use any of the RFC 1483 methods to bridge PPPoA - there's no way of terminating the PPP session.

    Meanwhile, there's no way that you'll need to set ATM settings like VPI and VCI in pfSense - pfSense has no ATM stack.

    If you need PPPoA, you need a router that has PPPoA half bridge for a single IP account, or supports no NAT routing for an IP netblock account. You may be able to get away with 1:1 NAT and port forwarding for a single IP account, but that's a messy solution that may not work perfectly.

    I'd ditch the ADSL router and replace it with one that has half bridge if you have a single IP ADSL account - ADSL routers are inexpensive now. If you can post a current model that has suitable support, that would be helpful. Googling around, Netgear DM111P might be a suitable device, complete with ADSL2+ support.

    With the DM111P, it sounds as if you select the WAN protocol to "PPPoA bridging", enter the rest of the details in the DM111P, then set pfSense to DHCP and things will work, but I can't verify this and I can't find a full user manual for this device. It's worth a look.

    (Edited to correct a couple of typos that impaired meaning)



  • It is based on this http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoa.html.

    While you speak about atm stack, if you need that you need even place a ATM card in pfSense which most people do not do since you need to find a supported card and not many people do that. VPI, VCI and a whole lot of other parameters you can configure for pppoa can be done on the modem.

    I used the 2 parts of those tutorials obn FreeBSD but after some pain kept the USB configuration since it does not have another device to be monitored that can go wrong and it seemed that the pppoa modem to be used with mpd was a crap one and the directly connected usb modem was more reliable(though it needed a lot of hacking back than on FreeBSD 5.[4,5]-RELEASE till FreeBSD 6-CURRENT at the time).

    It is limited to devices/routers that need this special pptp connection between them. For the others the standard connection would work.



  • And Bruce explains it better than me the limitation that PPPoA has in order to be used on normal pc
    http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-10/msg00241.html

    Be aware, that i do not think that many people would have a PCI adsl card at home and will mess around with the setting up of it.
    As i said you need to have patience and knowledge of what you are doing to set it up right.



  • @ermal:

    It is based on this http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoa.html.

    I'd regard the hardware mentioned there as barely worth supporting now. That handbook chapter represents the position as it was several years ago - its age is clear by the reference to Alcatel Speedtouch rather than Thomson Speedtouch (as it has been for some time).

    The Speedtouch Home could be configured to terminate the PPPoA connection and offered the connection onwards as PPTP (rather than the PPPoE that 3Com chose in their long obsolete router that I mentioned in my original post). The Speedtouch Home is long discontinued, replaced by hardware that supports ADSL 2+. It was old even amongst the 'original ADSL only' Speedtouch products.

    The nearest equivalent to the Speedtouch Home these days is the Speedtouch 546 v6. As this hardware is so cheap, I may well pick one up to experiment with; I need to order some GBICs and I could always add it to the order.

    It appears that Thomson refer to this PPPoA to PPTP connection as "Relayed PPPoA" - see here for configuration details for the business Speedtouch routers. Google also suggests that a Relayed PPPoA configuration profile is available for the Speedtouch 546 v6, but I can't confirm it.

    Certainly adding the option to terminate such a connection on pfSense makes sense - but maybe it should appear as "Relayed PPPoA (Speedtouch routers)" or similar in the GUI.

    I would regard the USB modem as utterly obsolete - the price of basic Ethernet ADSL devices is so low that USB devices have disappeared from the market. PCI ADSL cards have disappeared for pretty much the same reasons.

    I was talking about an ATM stack in the context of a PCI ADSL card, whilst commenting that the ATM stack in FreeBSD may not have the interest it once did as ATM networking in general is becoming less common. It's rare to come across an ATM NICs these days. For all the hope of ATM, it's increasingly being replaced by other technologies that have lesser overheads such as MPLS.

    Please don't think I'm trying to start an "I'm right, you're wrong" sort of argument here. My interest is in setting out the options as clearly as possible, and in talking about and supporting DSL hardware that's available today.

    It seems that the options for ADSL delivered using PPPoA are:

    "Half Bridge" and similar techniques such as the one mentioned in the the post from Bruce that Ermal mentioned (isn't the 'one up' IP address via DHCP that Bruce mentions what D-Link calls zipb?). This is suitable for single IP address PPPoA accounts. Netgear DM111P might be a suitable ADSL 2+ modem. Configure pfSense for DHCP on the WAN side - or if the (often very short) DHCP lease time is an issue, use DHCP to figure out the details then configure pfSense to the static IP - assuming that your WAN IP is static.

    Use an ADSL router with NAT and the firewall disabled. This needs a routed IP account, and uses one IP address from your pool of public addresses. ZyXEL P660H series are suitable ADSL 2+ routers. (If you have another flavour of DSL, such as SDSL or VDSL, the chances are that the corresponding ZyXEL Prestige router will work, though I can't guarantee it). Configure the router and pfSense as I mentioned in my original post.

    Speedtouch "Relayed PPPoA" with your pfSense patch, Ermal. Speedtouch 546 v6 might be a suitable ADSL 2+ router. Configure pfSense as Ermal describes.

    Any ADSL router you choose with one LAN IP address set as the DMZ address with all ports open to that address (or just turn the router's firewall off). This will work for single IP address PPPoA accounts, but you can get problems from this being 'double NAT' - also it's possible to exhaust the state table on the router. Configure pfSense to the IP address you set up in the router's DMZ feature. I would regard this as a less than ideal approach, but if it's the only one open to you, go for it!



  • Hi all,

    I'm in the same boat - set up a pfsense/route-modem configuration using PPPoE at home, and spent hours trying to work out why it didn't work when I installed it at work. Turns out the work line only supports PPPoA, whereas my home line supports both (but advocates PPPoA).

    Anyway…. after this week I've already forgotten far more about modems, encapsulation methods, DSLAMs, pure/half/RFC1483-bridge modes, double-NAT than I ever wanted to... argh  :o

    But I may have found a solution. It does involve throwing money at the problem, but at this point if it saves what remains of my hair....

    http://www.draytek.co.uk/products/vigor110.html

    I'm in no way affiliated, and make no claim as to the suitability of this device to solve any problems you may or may not have! But it does claim to specifically fix our PPPoA woes. Might be worth a punt?

    Hope this helps.

    sim



  • After 3 days of messing around with various ways to work around the problem of pfSense not being able to work with a PPPoA QWest ADSL line I hunted down the tech support for DrayTek in the US and talked to the guy about the Vigor 110.

    It really sounds like the right device. It is an ADSL modem and PPPoE/PPPoA bridge. It lets the ethernet device (my pfSense WAN interface in this case) pass authentication information to it in PPPoE and it re-encapsulates the information in PPPoA and sends it up to the DSLAM. From then on the ethernet device is directly bridged to the ADSL line and gets the public IP address by DHCP.

    The problem now is that the one place I found in the U.S. that sells them wants a minimum order of 1000 pieces. About 999 more than I have a need for right now. Has anyone found a U.S. source for these?

    Thanks, Bill


Locked