Getting private/local IP on WAN
-
@stephenw10 also I tested plugging in the router directly to my windows PC (it didn't get IP, I disabled DHCP in the VR600 while it's in bridge mode) and I went and created a new connection from settings and just used the username and password of my PPPoE connection that I used on the router and it worked. PPPoE connection succeeded. Now I'm trying to figure out why it'd work on windows and not in pfsense, using the same exact details.
-
How are you creating the connection in pfSense? Is it using the correct NIC?
-
@stephenw10 yes I have a PCI quad port intel NIC (igb0,igb1,igb2,igb3 and pfsense can see all the interfaces correctly, along with the on board realtek (rel0) and I tried testing with the onboard one but same result. The assignments have PPPoE on igb0 and the cable from port 1 from the router is connected to it and also in PPPs configuration is correct. The PPPoE connection working on windows means the bridge mode is actually working correctly right? and the problem is with pfsense?
-
Yes, that's what I would think. If you can establish a PPPoE connection from Windows it should work from pfSense.
You may need to power cycle the modem if it's locked to the MAC address. That's unusual for PPPoE connections but can happen.
-
@stephenw10 yea I tried that too
, and I even tried the mac address spoofing (took the mac address of the router and added it to the WAN config) and it didn't work too. -
If you spoof the MAC if should be the MAC of the Windows device. You can't use the MAC of the router as that is still in the link.
-
@stephenw10 I mean without using a windows device, just the cable between the router (in bridge mode) and the pfsense wan port I tried spoofing the mac of the router so that PPPoeE connection thinks its the same device but anyway I tried without spoofing too, same result. Do you think I should some how increase the timeout limit? even on the router itself and when testing dial up with windows it takes more than 10 seconds to get a connection.
-
Hmm, I really expect to see something even if it's a failure. The PPP logs you're seeing means nothing it coming back. Or at least it's not seeing it.
It behaves identically on re0 as any of the igb NICs?Try running a pcap on the parent NIC and see if it shows anything at all coming back from the modem or ISP.
Steve
-
its not returning anything. I didn't try pcap on re0 but the same thing was happening only time outs. What does this mean? I really appreciate your help, Steve.
-
@stephenw10 I also tried it on the same interface but chose the unassigned one and it gave this
-
Yeah the pcap needs to be on the PPPoE parent interface not the PPPoE itself. So on re0 or igb0 etc.
You won't see anything over the PPPoE until it connects.
-
@stephenw10 ok but this means it can actually reach the modem right? so what could be wrong?
-
@stephenw10 it is sending PADI and receiving PADO shouldn't it then send PADR to accept the connection and work? Any help is appreciated
-
can I somehow increase the time before it times out and retries? as it seems like it might not be seeing the PADO packet and just keeps retrying again and again while it actually does receive the PADO after a while, but never sends a PADR
-
Ah sorry missed your second post. Try either turning up the view mode to show more detail or download the pcap and open in wireshark. The replies from the PPPoE server might be telling you what's happening.
-
I tried exporting it into wireshark and looks very consistently trying but does get anything
-
Check the Ethernet properties on the replies. Is it tagged in some way?
-
I dont see any tags as far as I know, it's driving me crazy not knowing why it doesn't send back a PADR back after PADO
This is from the PADO coming back
Frame 223: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 21, 2023 01:48:21.525784000 EEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1695250101.525784000 seconds
[Time delta from previous captured frame: 1.948162000 seconds]
[Time delta from previous displayed frame: 1.948162000 seconds]
[Time since reference or first frame: 278.132417000 seconds]
Frame Number: 223
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:pppoed]
Ethernet II, Src: HuaweiTe_92:75:21 (8c:68:3a:92:75:21), Dst: IntelCor_48:da:98 (00:1b:21:48:da:98)
Destination: IntelCor_48:da:98 (00:1b:21:48:da:98)
Address: IntelCor_48:da:98 (00:1b:21:48:da:98)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: HuaweiTe_92:75:21 (8c:68:3a:92:75:21)
Address: HuaweiTe_92:75:21 (8c:68:3a:92:75:21)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: PPPoE Discovery (0x8863)
PPP-over-Ethernet Discovery
0001 .... = Version: 1
.... 0001 = Type: 1
Code: Active Discovery Offer (PADO) (0x07)
Session ID: 0x0000
Payload Length: 38
PPPoE Tags
Host-Uniq: c0b86a0100f8ffff
AC-Name: RMS-BNG-NE40X8A-04And this is the PADI that I send
Frame 226: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 21, 2023 01:48:23.579340000 EEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1695250103.579340000 seconds
[Time delta from previous captured frame: 0.132140000 seconds]
[Time delta from previous displayed frame: 2.053556000 seconds]
[Time since reference or first frame: 280.185973000 seconds]
Frame Number: 226
Frame Length: 36 bytes (288 bits)
Capture Length: 36 bytes (288 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:pppoed]
[Coloring Rule Name: Broadcast]
[Coloring Rule String: eth[0] & 1]
Ethernet II, Src: IntelCor_48:da:98 (00:1b:21:48:da:98), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: IntelCor_48:da:98 (00:1b:21:48:da:98)
Address: IntelCor_48:da:98 (00:1b:21:48:da:98)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: PPPoE Discovery (0x8863)
PPP-over-Ethernet Discovery
0001 .... = Version: 1
.... 0001 = Type: 1
Code: Active Discovery Initiation (PADI) (0x09)
Session ID: 0x0000
Payload Length: 16
PPPoE Tags
Host-Uniq: 00a8dd0100f8ffff -
@stephenw10 is there any way to override the timeout for waiting for PADO? It seems to timeout every 9 seconds and resend the PADI again & again and the PADO literally arrives 10-11 seconds after the first PADI
️ ️ -
Hmm, that timing seems very odd. I'd expect the server to respond far quicker than that.
There's no config option for that in the gui but you probably can set that via an mpd config option directly. Look in: /var/etc/mpd_wan.conf
If you can find an option that works you can create a custom file for that in /conf.
Steve
