From nobody Thu May 04 19:40:14 2023 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QC40g3kQnz49SRw for ; Thu, 4 May 2023 19:40:19 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Received: from nightmare.dreamchaser.org (ns.dreamchaser.org [66.109.141.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "discoveriesinwood.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QC40g10Gwz3D7J for ; Thu, 4 May 2023 19:40:19 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.151.122] (breakaway [192.168.151.122]) by nightmare.dreamchaser.org (8.16.1/8.16.1) with ESMTP id 344JeEgx001746; Thu, 4 May 2023 13:40:17 -0600 (MDT) (envelope-from freebsd@dreamchaser.org) Message-ID: <0054f586-e216-a1aa-8b2d-67d1e7c931c7@dreamchaser.org> Date: Thu, 4 May 2023 12:40:14 -0700 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Reply-To: freebsd@dreamchaser.org Subject: Re: PPPoE bridge / vlan? setup help needed Content-Language: en-US To: Ian Smith Cc: questions@freebsd.org References: <7c972cc1-3c49-ad0a-b86f-91bd0b978537@dreamchaser.org> <9A04451E-1BC7-402D-A5A5-B1B6466DBE56@FreeBSD.org> <547039FF-357F-4B16-80C6-D2AC2B710C38@nimnet.asn.au> From: Gary Aitken In-Reply-To: <547039FF-357F-4B16-80C6-D2AC2B710C38@nimnet.asn.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (nightmare.dreamchaser.org [192.168.151.101]); Thu, 04 May 2023 13:40:17 -0600 (MDT) X-Rspamd-Queue-Id: 4QC40g10Gwz3D7J X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:21947, ipnet:66.109.128.0/19, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5/3/23 15:02, Ian Smith wrote: > 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. Understood. I've been running a fbsd firewall for ~20 years, but always behind a router; the router pretty much was a pass-through. > 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. My choice is like being outback ... pretty much <=1. > 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) Got it, yes. That was the missing piece of the puzzle, which my ISP didn't want to talk about. Kept insisting all I needed to do was use the IP assigned to the /29 address. > Also, gateway there refers to the modem/router's gateway, not yours. understood. > a fresh set and a pretty > paranoid firewall wouldn't hurt. yeah, I mulled that over a lot and decided it was probably too confusing to talk about and try to get all the substitutions right in the traces. Thanks for the suggestions. > 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. ...> No, you accepted the address they offered as _their_ end of the ppp > link. Ok, thanks. Looking at the trace again, please correct if I'm wrong; trying to make sure I understand it: 1 IPCP: deflink: SendConfigReq(1) state = Closed 2 IPCP: IPADDR[6] MY.PROPADDR.MY.END 3 IPCP: COMPPROTO[6] 16 VJ slots with slot compression 4 IPCP: deflink: State change Closed --> Req-Sent 1-4 I send isp proposed addr for my end 5 LCP: deflink: RecvProtocolRej(79) state = Opened 6 LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! 7 CCP: deflink: State change Req-Sent --> Stopped 5-6 I receive his *protocol* rejection of CCP compression protocol I assumed this meant he accepted the address. But instead I have to send a whole new proposal? Or is it uncertain at this point? Could he still send me an ack for the addr instead of reject? 8 IPCP: deflink: RecvConfigReq(223) state = Req-Sent 9 IPCP: IPADDR[6] HIS.PROPADDR.HIS.END 10 IPCP: deflink: SendConfigAck(223) state = Req-Sent 11 IPCP: IPADDR[6] HIS.PROPADDR.HIS.END 12 IPCP: deflink: State change Req-Sent --> Ack-Sent 8-12 I receive his proposed addr for his end and accept it 13 IPCP: deflink: RecvConfigRej(1) state = Ack-Sent 14 IPCP: COMPPROTO[6] 16 VJ slots with slot compression 13-14 I receive his rejection of my original entire config request Since it's a config reject, as opposed to a protocol reject, the reject includes/implies the proposed addr, not just the compression protocol he tells me about? 15 IPCP: deflink: SendConfigReq(2) state = Ack-Sent 16 IPCP: IPADDR[6] MY.PROPADDR.MY.END 15-16 I resend isp my proposed addr for my end 17 IPCP: deflink: RecvConfigNak(2) state = Ack-Sent 18 IPCP: IPADDR[6] HIS.PROPADDR.MY.END 17-18 I receive his nak of my proposed addr, along with his proposal for my end. 19 IPCP: HIS.PROPADDR.HIS.END: Unacceptable address! 19 I give up because of my limits on addrs on my end. >> I tried using 0.0.0.0 as my suggested IP, to see if they would >> come up with the HIS.PROPADDR.MY.END 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] HIS.PROPADDR.MY.END >> 5 tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> HIS.PROPADDR.MY.END > > Correct! > >> 6 tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent >> 7 tun0: IPCP: IPADDR[6] HIS.PROPADDR.MY.END >> 8 tun0: LCP: deflink: RecvTerminateReq(8) state = Opened > > Opened is ok, we're only terminating LCP section I expect. Anything > after that? 9 LCP: deflink: LayerDown 10 LCP: deflink: SendTerminateAck(8) state = Opened 11 LCP: deflink: State change Opened --> Stopping 12 CCP: deflink: State change Stopped --> Closed 13 CCP: deflink: State change Closed --> Initial 14 Phase: deflink: open -> lcp 15 Warning: ff02::/: Change route failed: errno: Network is unreachable 16 IPCP: deflink: State change Ack-Sent --> Starting 17 IPCP: deflink: LayerFinish. 18 IPCP: Connect time: 0 secs: 0 octets in, 0 octets out 19 IPCP: 0 packets in, 0 packets out 20 IPCP: total 0 bytes/sec, peak 0 bytes/sec on Tue May 2 09:18:03 2023 21 IPCP: deflink: State change Starting --> Initial 22 Phase: bundle: Terminate 23 LCP: deflink: LayerFinish 24 LCP: deflink: State change Stopping --> Stopped 25 LCP: deflink: State change Stopped --> Closed 26 LCP: deflink: State change Closed --> Initial 27 Phase: deflink: Disconnected! 28 Phase: deflink: lcp -> logout 29 Phase: deflink: logout -> hangup 30 Phase: deflink: Disconnected! 31 Phase: deflink: Connect time: 4 secs: 113 octets in, 144 octets out 32 Phase: deflink: 8 packets in, 9 packets out 33 Phase: total 64 bytes/sec, peak 85 bytes/sec on Tue May 2 09:18:04 2023 34 Phase: deflink: hangup -> opening 35 Phase: bundle: Establish 36 Phase: deflink: Enter pause (3) for redialing. 37 Chat: deflink: Reconnect try 1 of 0 38 Chat: deflink: Redial timer expired. 39 Phase: deflink: Connected! 40 Phase: deflink: opening -> dial I terminated the ppp session, thinking the warning at line 15 meant it didn't work. However, I'm not certain at what point I terminated it; maybe a bit too soon. I think #22 above is me killing the process. But I'm a bit wary of saying that as it seems too timely. #22 immediately follows #21, but there's a 3 second delay between #22 and #23. This a.m. I started out proposing HIS.PROPADDR.MY.END and the link came up, immediately followed by: (Note: HIS.PROPADDR.MY.END is actually what *I* proposed) ... 1 IPCP: deflink: RecvConfigAck(2) state = Ack-Sent 2 IPCP: IPADDR[6] HIS.PROPADDR.MY.END 3 IPCP: deflink: State change Ack-Sent --> Opened 4 IPCP: deflink: LayerUp. 5 IPCP: myaddr HIS.PROPADDR.MY.END hisaddr = HIS.PROPADDR.HIS.END 6 Warning: ff02::/: Change route failed: errno: Network is unreachable 7 LCP: deflink: RecvEchoRequest(0) state = Opened 8 LCP: deflink: SendEchoReply(0) state = Opened 9 DNS: OUTbound query IN AAAA 0.freebsd.pool.ntp.org. ... I don't know if #9 means #9 actually went out or not. When I looked at the routing table, I saw: Destination Gateway Flags Netif Expire 1 default HIS.PROPADDR.HIS.END US tun0 2 HIS.PROPADDR.MY.END link#4 UHS lo0 3 MY.NET.MY.END/29 link#1 U xl0 4 MY.NET.MY.END link#1 UHS lo0 5 HIS.PROPADDR.HIS.END link#4 UHS tun0 ... As I see it, a request going out not in my subnet out would match 1. If it gets to tun0, I presume it's going out. If so, where is the network unreachable, which is in every trace whether it succeeds or not, coming from? Is it true that something sent to xl0, which is the target for natd in my firewall rules, will "do the right thing" via tun0, even with nothing additional in the routing table? I'm not sure I really understand the above routing table with tun0 inserted: tun0 -> xl0 (HIS.PROPADDR.MY.END) -> HIS.PROPADDR.HIS.END) -> world MY.NET.MY.END part of MY.NET.MY.END/29 -> xl0 -> ??? or MY.NET.MY.END same as HIS.PROPADDR.MY.END -> ??? This feels like why I want MY.NET.MY.END and not HIS.PROPADDR.MY.END. Thanks, Gary