Bogon Alias address created for pppoe WAN

dandare100

Ok, so I have booted into the previous environment and the same happens so it not related to the upgrade.

Could someone help me understand the "default dynamic" gateway that is created for the WAN interface.

Specifically, should it be the same "public" ip address as what the WAN is ?

This is the output of ifconfig for the pppoe interface

pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
	description: WAN
	options=0
	inet 155.xxx.xxx.xxx --> 100.64.0.225 netmask 0xffffffff
	inet6 fe80::xxxxxxxxxxxxxxxxxxxxxxx prefixlen 64 scopeid 0x11
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Here is the output of the pppoe logs

Jan 14 08:34:59	ppp	46832	[wan_link0] LCP: authorization successful
Jan 14 08:34:59	ppp	46832	[wan_link0] Link: Matched action 'bundle "wan" ""'
Jan 14 08:34:59	ppp	46832	[wan_link0] Link: Join bundle "wan"
Jan 14 08:34:59	ppp	46832	[wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Jan 14 08:34:59	ppp	46832	[wan] IPCP: Open event
Jan 14 08:34:59	ppp	46832	[wan] IPCP: state change Initial --> Starting
Jan 14 08:34:59	ppp	46832	[wan] IPCP: LayerStart
Jan 14 08:34:59	ppp	46832	[wan] IPCP: Up event
Jan 14 08:34:59	ppp	46832	[wan] IPCP: state change Starting --> Req-Sent
Jan 14 08:34:59	ppp	46832	[wan] IPCP: SendConfigReq #1
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 0.0.0.0
Jan 14 08:34:59	ppp	46832	[wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 14 08:34:59	ppp	46832	[wan] IPCP: rec'd Configure Request #1 (Req-Sent)
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 100.64.0.225
Jan 14 08:34:59	ppp	46832	[wan] 100.64.0.225 is OK
Jan 14 08:34:59	ppp	46832	[wan] IPCP: SendConfigAck #1
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 100.64.0.225
Jan 14 08:34:59	ppp	46832	[wan] IPCP: state change Req-Sent --> Ack-Sent
Jan 14 08:34:59	ppp	46832	[wan_link0] rec'd unexpected protocol IPV6CP, rejecting
Jan 14 08:34:59	ppp	46832	[wan_link0] rec'd unexpected protocol MPLS Control Protocol (RFC 3032), rejecting
Jan 14 08:34:59	ppp	46832	[wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 14 08:34:59	ppp	46832	[wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 14 08:34:59	ppp	46832	[wan] IPCP: SendConfigReq #2
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 0.0.0.0
Jan 14 08:34:59	ppp	46832	[wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 155.xxx.xxx.xxx
Jan 14 08:34:59	ppp	46832	[wan] 155.xxx.xxx.xxx is OK
Jan 14 08:34:59	ppp	46832	[wan] IPCP: SendConfigReq #3
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 155.xxx.xxx.xxx
Jan 14 08:34:59	ppp	46832	[wan] IPCP: rec'd Configure Ack #3 (Ack-Sent)
Jan 14 08:34:59	ppp	46832	[wan] IPADDR 155.xxx.xxx.xxx
Jan 14 08:34:59	ppp	46832	[wan] IPCP: state change Ack-Sent --> Opened
Jan 14 08:34:59	ppp	46832	[wan] IPCP: LayerUp
Jan 14 08:34:59	ppp	46832	[wan] 155.xxx.xxx.xxx -> 100.64.0.225
Jan 14 08:34:59	ppp	46832	[wan] IFACE: Up event
Jan 14 08:34:59	ppp	46832	[wan] IFACE: Rename interface ng0 to pppoe0
Jan 14 08:34:59	ppp	46832	[wan] IFACE: Add description "WAN"

Does this mean I am being CGNAT'ed ?

I am battling to understand the "-->" notation, in both of the outputs above.

Gertjan

@dandare100 said in Bogon Alias address created for pppoe WAN:

Does this mean I am being CGNAT'ed ?

Not sure.
What was the 'final' IP WAN you received ?

Btw : your ISP send you more info when creating the connection, like :

rec'd unexpected protocol IPV6CP, rejecting

but on your side, pppoe rejected it ?
Do you ask for a IPv6 connection also on your side ? Is it set to none on you side ?

edit :
@dandare100 said in Bogon Alias address created for pppoe WAN:

inet 155.xxx.xxx.xxx --> 100.64.0.225 netmask 0xffffffff

I would presume that 155.xxx is your QWAN IP, and 100.64.xxxx (smells like cgnat) is your gateway. This would be the IP dpinger is using to 'ping' it for connection alive tests.
The fun part is : if this 100.64.xxxx doesn't reply to pings then the connection would - default behaviour - considered as "not up".

That's why you can chose another IP to ping for the connection to be tested.
The best IP would be an IP as close to you, or, if searching isn't your thing, use what other do :

Just for fun : the day Google decides that 8.8.8.8 shouldn't be replying to 'ping' anymore will disconnect billions ^^

You can also test with disabling the gateway action (== resetting the connection, and rebuilding it) or not monitoring and consider it as always up (for a pppoe this isn't probably the case).

dandare100

@Gertjan said in Bogon Alias address created for pppoe WAN:

What was the 'final' IP WAN you received ?

I am not sure what you mean by "final", apologies.
So am I correct in saying that my WAN interface gets the public ip of 155.xxx.xxx.xxx but the gateway is 100.64.0.225 (on the ISP's side) ?

@Gertjan said in Bogon Alias address created for pppoe WAN:

Do you ask for a IPv6 connection also on your side ? Is it set to none on you side ?

It is set to none on my side because my ISP does not support IPv6 in this region yet. I am not sure why it's coming through from the server as an option.

dpinger is working well with the 100.64.0.225 and reports it as up.

I am not experiencing any issues. The main reason for my post is to understand where the 100.64.0.225 is coming from. It wasn't there before.
I raised it with my ISP and they suggested that I request a permanent/static IP if I did not want to be CGNAT'ed.

I did so, but the 100.64.0.225 remains in place even after moving to a static IP.

@Gertjan said in Bogon Alias address created for pppoe WAN:

Just for fun : the day Google decides that 8.8.8.8 shouldn't be replying to 'ping' anymore will disconnect billions ^^

Eish, lol

Thank you for the replies, it is appreciated

Bob.Dig

@dandare100 Go to https://whatismyipaddress.com/ and if it shows the same IP as your WAN-IP in pfSense, you are not NAted. And a gateway is not the same as the interface-ip address. It doesn't matter if it is from the CG-NAT range or whatever.

Gertjan

@dandare100 said in Bogon Alias address created for pppoe WAN:

I am not experiencing any issues. The main reason for my post is to understand where the 100.64.0.225 is coming from. It wasn't there before.

You can compare pppoe with what DHCP does.
When a devices (example : a LAN PC)emits a request for a DHCP lease, the DHCP server (for example pfSense) gives the client a
IP, like 192.168.1.10
Network, like 25.255.255.0
A gateway IP, which is the pfSense LAN IP, for example 192.168.1.1
A DNS IP, which is the pfSense LAN, so the device know who it can contact to do DNS searches.
( more info can get requested, like, for example, a NTP IP)

The gateway is very important.
Because the IP received is 192.168.1.10, and the network 'mask' is 255.255.255.0, the device now knows that it can contact all IP's from 192.168.1.1 to 192.168.1.254 directly. All other IPs, all other network, like the entire internet, can be reached by using the gateway. Typically, the gateway knows how to route, as it is a router ^^
Your 100.64.0.225 is probably the router the pfSense WAN uses to go "the Internet".
A CGNAT IP btw.

dandare100

@Bob-Dig Done and it matches the public ip in pfsense, thanks

dandare100

@Gertjan Thank you for the explanation, makes sense.

It just seems weird that the ISP is assigning the "100.64.0.225" as the gateway for a pppoe interface with a public ip address.

I understand that I am not a network fundi :-) and that this setup may be completely normal, I am just trying to understand the setup because it was not previously like that.

Bob.Dig

@dandare100 It is just efficient. Your ISP is saving on public-IPv4-space.

My WAN looks like this.

IPv4 Address
    46.*.*.* 
Subnet mask IPv4
    255.255.255.255 
Gateway IPv4
    94.*.*.*

You can see, there is no relationship between the IP-address on my WAN and its gateway.

dandare100

@Bob-Dig Ok cool. Thank you. I understand now and will let it go.

Thanks for the patience guys

johnpoz

@Bob-Dig said in Bogon Alias address created for pppoe WAN:

You can see, there is no relationship between the IP-address on my WAN and its gateway.

I wouldn't say that - that is not how a typical network is setup.. Normally the gateway off a network, needs to be on the network your trying to get off of, how else would you get there. But yes you can go against normal practice. Multiple layer3 on the same layer 2.. Where the IP is different layer 3 but your on the same layer 2 network so the client can get the mac of its gateway.

PPPoe is a tunnel so its a bit different. But normally the gateway would and should be on the same network space.. If its not you normally have to let the client know this.

If you go into routing and, and look at your dhcp gateway - if that IP is outside your network you get - you would normally have to set this.

https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html#advanced-gateway-settings

The Use non-local gateway through interface specific route option allows a non-standard configuration where a gateway IP address exists outside of an interface subnet. Some providers attempting to scrape the bottom of the IPv4 barrel have resorted to this in order to not put a gateway into each customer subnet. Do not activate this option unless required to do so by the upstream provider.

Normally if you manually set that - the OS should scream at you.

So while it "can" be done - it is not your typical setup..

When a client decides that hey this IP is not on my network, I need to send it to my gateway - it would arp for the mac address of the gateway (that is on its network) and send the traffic there.. In a typical setup if the gateway is not on the same network, how would the client get the mac to actually send the traffic to.. So there are some caveats to be sure if doing such a setup.. So please don't get the idea that you can make your network 192.168.1.0/24 and just set a gateway as 192.168.2.1 and it will work.

Bob.Dig

@johnpoz said in Bogon Alias address created for pppoe WAN:

When a client decides that hey this IP is not on my network, I need to send it to my gateway - it would arp for the mac address of the gateway (that is on its network) and send the traffic there.. In a typical setup if the gateway is not on the same network, how would the client get the mac to actually send the traffic to..

@johnpoz I am curious. Normally it would arp for the MAC of the gateway. Now when this is not on its network, it would still arp for the MAC of the gateway? So it is basically the same? What are the caveats of this approach.

johnpoz

@Bob-Dig clients don't normally arp for an IP that is not on their own network. This is why you need to tell the device - hey that is your gateway you can talk to it on the same L2 network, so you can get the mac if you arp.

Bob.Dig

@johnpoz So it is basically the same.
I am asking because I have a VPS and proxmox on it. The VPS-Provider gave the following, single IP-configuration: IP 5.5.5.5/24, Gateway 5.5.5.1

In Proxmox, the local subnet has more rights, for instance, it doesn't get blocked if it uses the wrong credentials too many times.
That is why I changed the network config on that VPS to be: IP 5.5.5.5/32, Gateway 5.5.5.1

No questions asked, it just works (Debian).

Bob.Dig

@johnpoz said in DNS Rebind attack conditions doesn't make sense:

if pfsense has no portward to itself then it must think that IP is his.

Really, his?

johnpoz

@Bob-Dig You can set the gateway to any IP you want, but its not a normal, typical setup - and like the warning I showed you - the OS thinks you must of made a typo ;) It might still arp for it since its gateway IP and has to be reachable on the same L2

But you can not be sure device or OS will do that. Nor can you be sure what your arping for will answer if the IP is not on the gateways network IP range.