Re: PPPoE bridge / vlan? setup help needed
- In reply to: Ian Smith : "Re: PPPoE bridge / vlan? setup help needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 04 May 2023 19:40:14 UTC
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