PPPOE wan will not connect -
-
@biggsy said in PPPOE wan will not connect -:
Try removing the Service name "IINET".
See the log file above.
Search for that one moment where everything goes well : "bri-apt-wic-bras207".
pfSense sends always the same data, but the connection doesn't come up often.
And if it comes up, and 'identification' works out well (so : all local settings are ok !!) then connection is dropped right after tat moment.Way back, their was the hard core PPPOE connect method :
Shut down everything.
Start the modem - and wait for at least 5 minutes.
Now start pfSense.
If that doesn't work.
Shut down everything.
Wait for 24 houres (I know ... it's just a test)
Now start modem and wait at least 5 minutes.
Start pfSense.The thing that bothers that : why some other device can connect ?
And did you test this : your PC can also do 'PPPoE' : select that type of connection, connect the PC to the modem, and check if it connects. -
Were you able to get a connection log from either of the other devices that can connect?
-
@gertjan Hi Steve. Sorry for delay.
Was trying to get a fresh perspective on all of the issues.
I have done what you suggested above. no change except the log files shrank to up and down mostly :) over and over again.
I even tried spoofing the mac address on the Wan interface and no luck
If I change it from PPPOE to DHCP, I get a green Wan interface immediately with 0.0.0.0 as an IP. obviously because there is no authentication happening there.
I am not sure what else to try here.
Fresh installs, changes, guides, forums, I am stumped.
Why is it so difficult., When the USG PRO just works -
@gerryatric said in PPPOE wan will not connect -:
When the USG PRO just works
Can you get by any chance from the USG a connect log that shows how the USG makes the connection? That might be helpful.
-
@gerryatric said in PPPOE wan will not connect -:
When the USG PRO just works
Then I repeat :
@stephenw10 said in PPPOE wan will not connect -:
Were you able to get a connection log from either of the other devices that can connect?
Or this one :
@stephenw10 said in PPPOE wan will not connect -:
Check the ppp logs in the ER or any other router that does connect.
For example :
-
I just found something over on Whirlpool that suggests setting an MTU of 1500 and disabling VJ compression (Interfaces > PPPs > Edit, Advanced Options).
The poster then edited to say an MTU of 1500 was enough.
-
Mmm, easy test at least.
-
@biggsy Hi
Same issue. that didn't do anything either sadly -
@gerryatric The MTU setting on my Wan port on the USG is 1440
Apparently it needed to be lower to get the speed up.
When I first connected I had 1492 in .
I couldn't get above 200mbps.
So I rang IINEt and to get Ultrafast speed on fibre, you need to lower the MTU. They gave me a couple numbers and 1440 worked the best. -
The MTU when using pppoe, in the inside, can never be 1500.
Classic pppoe is 1472 or something close to that.
Yours is encapsed in a VLAN, so even less ?
Dono what an MRU is.Btw : you can determine what the best value is :
ping with a given packet size (the default is 60 bytes so it always passes) - and check the answers for 'fragmentation'.
Repeat the test, start at 1400, and add 4 on every next test.
As soon as 'fragmented comes back, you found your MTU value.
There are many how-to available on the net.This test needs a working connection, of course.
-
@gertjan yep I did that with IINEt when setting up the USG, we deduced that 1440 was the best settings with the ping.
That still doesn't explain why it won't connect though. -
In your earlier logs, just after the ntp lines @Gertjan referenced, there is this sequence:
192.168.200.3 Sep 14 12:01:18 daemon info ppp[52996] [wan] 118.208.207.22 -> 10.20.26.62 192.168.200.3 Sep 14 12:01:18 daemon info ppp[52996] [wan] 118.208.207.22 -> 10.20.26.62 192.168.200.3 Sep 14 12:01:19 user notice check_reload_status[374] rc.newwanip starting pppoe0 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Up event 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Up event 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Rename interface ng0 to pppoe0 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Rename interface ng0 to pppoe0 192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 36 pppoe0 118.208.207.22:123 192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 37 pppoe0 [fe80::215:17ff:febf:f4cc%8]:123 192.168.200.3 Sep 14 12:01:20 daemon err php-fpm[24661] /rc.newwanip: rc.newwanip: Info: starting on pppoe0. 192.168.200.3 Sep 14 12:01:20 daemon err php-fpm[24661] /rc.newwanip: rc.newwanip: on (IP address: 118.208.207.22) (interface: WAN[wan]) (real interface: pppoe0). 192.168.200.3 Sep 14 12:01:20 user warning dpinger[93646] send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.20.26.62 bind_addr 118.208.207.22 identifier "WAN_PPPOE " 192.168.200.3 Sep 14 12:01:22 user warning dpinger[93646] WAN_PPPOE 10.20.26.62: Alarm latency 0us stddev 0us loss 100% 192.168.200.3 Sep 14 12:01:22 daemon info rc.gateway_alarm[95871] >>> Gateway alarm: WAN_PPPOE (Addr:10.20.26.62 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%) 192.168.200.3 Sep 14 12:01:22 user notice check_reload_status[374] updating dyndns WAN_PPPOE
I'm just wondering where that 10.20.26.62 might have come from. Not something I'd expect iiNet to set.
Could that be one of your home subnets?
Edit: Or are you perhaps running a PPPoE server on your USG or ER?
-
@biggsy Hi Phil
I have no idea where that is coming from. It isn't there immediately.
I have no gear on the local lan producing a 10.20.26.0 range at all
I am running ZeroTier SD Wan software on some of my nodes but that is machine dependent. must have a client installed. and it is not in that range anyway.
I do not know where that is coming from -
I think we need to find what's handing out that RFC1918 address. That looks like it's totally confusing PPPoE on your WAN.
Maybe a port mirror on the SR2024 and packet capture would tell us. I can't help with the Cisco stuff, unfortunately.Maybe not. Seems the SR2024 is unmanaged.
-
@biggsy yes it is just an unmanaged switch used to split the nbn signal is all. has the usg and the edgerouter connected to it
-
Having a private IP as the gateway for PPPoE is not that unusual and works fine. Both of mine are like that. Is that public IP in a range you expect?
I still find it odd that you are able to connect more that one client at a time though. Especially in a setup where it appears the password is not checked.
Steve
-
@stephenw10 said in PPPOE wan will not connect -:
I still find it odd that you are able to connect more that one client at a time
Agree
Would suggest connecting just one pfsense client as a test. -
@patch Ho
have done that many times. directly to the wan port from the fibre box. no luck -
@gerryatric
Why is it that you are using a vlan again?
You do have to connect to the correct physical lan port on the NBN fibre to the home modem/router
https://help.iinet.net.au/set-ftthbut vlan is not a prominent requirement on my reading of it.
Also when changing your router, how long did you wait for NBN to accept your new router. Aussie Broadband enables the user to kick the connection to accelerate this process, not sure how to do this with iiNet.
-
@gerryatric No as per the many above messages. IINET NBN fibre require their connections to use a vlan id.
so we have to use it. it is working on the USG and the edgerouter. just not Pfsense.
I don't need to kick any connection or wait for it to timeout as I can run multiple wan connections at same time.