Re: PPPoE bridge / vlan? setup help needed
- Reply: Gary Aitken : "Re: PPPoE bridge / vlan? setup help needed"
- In reply to: Gary Aitken : "Re: PPPoE bridge / vlan? setup help needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 03 May 2023 22:02:22 UTC
On 4 May 2023 3:49:57 am AEST, Gary Aitken <freebsd@dreamchaser.org> wrote: > Thanks all for your replies; > Slow following up; trying not to ask questions I can find the answer > to somewhere else, trying to do my due diligence... No worries, but don't hesitate to ask (as I too often do :) > On 5/2/23 00:37, Kristof Provost wrote: > > On 2 May 2023, at 3:32, Gary Aitken wrote: > >> Having trouble setting up a dsl modem as a bridge. ISP info: Fixed > > >> IP LLC-Based multiplexing VPI 0 VCI 100 > ... > > With the disclaimer that it’s been ~15 years since I last looked at > > > the relevant tech, but I think you’re confusing PPP over ATM > (PPPoA) > > with PPP over Ethernet (PPPoE). > > > > VPI/VCI are ATM concepts, and do not exist in Ethernet land. > Having never done this before I've had trouble understanding how to > go about it, and more trouble finding info. Obviously have/had some > things cross-wired in my head, and probably still do. 10 years ago, everyone knew about DSL modems; now, rarer in rich countries. > It's my understanding that the modem connects to the ADSL line using > ATM technology, and as such uses the vpi and vci I've given it in its > configuration. As nearly as I can tell it makes that connection ok. > In its status report I see the line up and at the proper speed, > proper > vpi and vci. It also reports the IP addr and mask for my LAN end of > the link, but no IP info for the ADSL port. Correct. > So the question becomes how does it connect to the fbsd firewall? > Do I actually need to run ppp or mpd if it's bridged? Yes. Your choice is to run the unit as a router plus modem (router mode, where it handles the PPPoE|A connection) or 'just' a modem, handing off raw frames to your PPPoE client, such as userppp or mpd5. You've chosen to run it as a bridge, which has advantages but also some difficulty, as you're experiencing. One advantage that's a difficulty if you get it wrong is that the (likely limited) firewall in the modem plus router mode is now up to you. I call that a plus, but plenty would rather not. > In talking to my ISP, who's limiting information because they > don't like to deal with customer-owned equipment (i.e. not rented > from them, but also understandably avoid the time needed to educate > the uneducated), I asked if in bridged mode they ran PPPoE or PPPoA, > and he said the modem should "just connect to the firewall machine > like any other network". Yeah, sorry ... mosf ISP helpdesk drones know 10% of SFA. Finding the right ISP is more than half the challenge, so ignore my suggestions to seek help there. > so I could be wrong, but I tried leaving ppp out of the link: Couldn't work, but clues from addresses: > Relevant IPs reported by modem in modem-router mode, linked up: > ADSL Port: > 66.109.136.47 255.255.255.255 ADSL link IP > 69.51.80.35 gateway address Ok, 66.109.136.47/32 is the local PPP (point to point protocol) address. That's the one your initial setup, below, refused to accept, because your end was insisting on "my.isp.assigned.ip" which I think is your address in your assigned /29, NOT the (also probably fixed) IP address of your side of the PPP link (...47) As mentioned in offlist mail, a separate IP addr to your routed subnet, whether fixed or dynamic, is or was common for ppp, and what my /29 had for years. Also, gateway there refers to the modem/router's gateway, not yours. I'm dropping the rest of this explore ... [ ... ] > Upshot of all that is it looks like a direct connection without PPPoE > doesn't work. Right. > Aside: I ISP asked about renting their preferred modem > (Zyxel VMG 4005 B50B) > and they said they don/t rent them separately, you have to rent them > with their preferred router... Also looked but couldn't find one > elsewhere. I'd be looking for another ISP, myself. And having published your various IP ranges, a fresh set and a pretty paranoid firewall wouldn't hurt. Trimming ... > > Not sure you need the '!' ? > > Without the ! it won't overwrite an old existing one. Ok, ppp(8). > >> tun0: CCP: deflink: LayerStart. > >> tun0: CCP: MPPE: Not usable without CHAP81 > > > > This looks maybe ominous. > > I wondered about that but thought it would just send uncompressed? > I haven't seen ppp options to set no compression. No, but likely deflate or pred1 is ok. > So at this point hoping for the best, you get a nak and don't do it. The nak is only for MPPE (multilink?) > Docs from Allied Telesis > https://www.alliedtelesis.com/sites/default/files/ppp_feature_config_guide_rev_b.pdf > says the config request is a "wish list", and if it gets a nak or > reject reply it should come up with a new wish list. I think I see Indeed. > that sent out in the lines: > IPCP: deflink: SendConfigReq(2) state = Ack-Sent > IPCP: IPADDR[6] 66.109.141.58 > right before the reject of the other address. > I'm inferring that a reject reply allows for renegotiation but a nak > is a flat-out can't do it, given that the nak (unacceptable address) > on the other addr later results in closing the connection. Yeah, I'm pretty sure the only real problem here is asking for the wrong local ppp address. Ask for 0.0.0.0/0 and later ask for what you get, if you like. > >> tun0: IPCP: deflink: RecvConfigRej(1) state = Ack-Sent > >> tun0: LCP: deflink: SendIdent(1) state = Opened > >> tun0: LCP: MAGICNUM 3bbf5181 > >> tun0: LCP: TEXT user-ppp 3.4.2 > >> tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression > >> tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent > >> tun0: IPCP: IPADDR[6] my.isp.assigned.ip Yep. that's the (2nd) ask for the wrong address so ... > >> tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent > >> tun0: IPCP: IPADDR[6] 66.109.136.47 No, they need you to accept this one! > not worry about it. Uh-huh. Repeated when I said "but that's the > addr > which is causing trouble.) > > >> *** tun0: IPCP: 66.109.136.47: Unacceptable address! No, it's unacceptable because you've insisted on an addfress in your /29, which is wrong. > > So you reject it. Maybe if you don't insist on > 'my.isp.assigned.ip' > > it might go - but then they've provided the wrong info. Not wrong, just confused. Most customers a) use their router and b) have a single IP address. > Thought maybe I reject it because it's not in my /29; or because I > already accepted the previous addr they asked for. No, you accepted the address they offered as _their_ end of the ppp link. > I suppose if it's > not in my /29 and I accepted it, all I would need to do is add a > route > to the routing table, which might happen automatically with the > add! default HISADDR. From your box in the /29, you just need to have the default route via the ppp IP, which ppp should determine as HISADDR which is reached via our ppp link addr. Don't force anything, it should go. > I tried using 0.0.0.0 as my suggested IP, to see if they would come > up with the 66.109.136.47 the first time: > > 1 tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent > 2 tun0: IPCP: IPADDR[6] 0.0.0.0 > 3 tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent > 4 tun0: IPCP: IPADDR[6] 66.109.136.47 > 5 tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 66.109.136.47 Correct! > 6 tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent > 7 tun0: IPCP: IPADDR[6] 66.109.136.47 > 8 tun0: LCP: deflink: RecvTerminateReq(8) state = Opened Opened is ok, we're only terminating LCP section I expect. Anything after that? > So when I send back a config request to use that addr on line 7 > why do I get a terminate back? > It would be really handy to be able to see the negotiation on the > back side of the modem, but I have no way to do that. In bridge mode, all negotiation happens in ppp. You are seeing it all, but it can be confusing groking what it means ... > > At this stage I'd send them the log and ask what's up? Yeah, nah ... > I think I'm going to try mpd first, if I can figure that out without > documentation other than the example.conf. I think ppp is ready to go, once you stop expecting it to use an addr in the /29 > > We moved from user ppp to mpd C. '07, and found it better and > easier, > > but that won't help if their setup info is wrong. > > Thanks, I'll see if I can figure out mpd and maybe it will work > better. > Have the mpd5 port installed, but I can't seem to find docs anywhere. % find /usr/local -name mpd5\* > The Handbook, ch 29.5.1, refers to a "Complete guide to configure > mpd" > in /usr/ports/shared/doc/mpd. There is no /usr/ports/shared, and I > see nothing other than mpd5 in /usr/ports that looks like it might be > relevant. Also nothing in /usr/local/share/doc/. See mpd5(8) /usr/local/share/doc/mpd5/ has a 70 odd page html manual. Maybe overkill, it's a powerful beastie, including PPPoE servers and other exotica. But seriously, if ppp still isn't working, post another log segment ( with config ) cheers, Ian