You are, once again, awesome. Thanks!
1 Like
@anon50098793 sorry for off topic
but can you please tell me what banIP source to use? is it good to turn on?
and can you use both simple ad block and banIP
no expert but i've been running these lists for 12+months and they've worked well for me;
list ban_sources 'bogon'
list ban_sources 'darklist'
list ban_sources 'debl'
list ban_sources 'drop'
list ban_sources 'dshield'
list ban_sources 'firehol3'
list ban_sources 'threat'
list ban_sources 'voip'
list ban_sources 'yoyo'
simple-adblock + banip should work together...
the thing with banip is... as openwrt is typically closed from the outside... what it's mostly catching is rogue client traffic on a typical home install... ( still really good... )
i'd recommend everyone enable and run it... on our devices it's no sweat for it... and it's an extra layer to keep out / be aware of dubious transmissions, that's pretty much a set and forget service... with little to no false positives...
3 Likes
kinda ot. pardon me.
i am in a bit of a dead end for me.
i am running latest snapshot, r17900.
rpi4 is a wireguard client.
i can ping ip's and domains from clients connected to lan-side of rpi4 inside of the vpn and wan-side.
so the wireguard tunnel works and internet works.
but i still can't access any websites. opkg update and the rpi4 update-check also don't work.
so its seems like dns-problem, but pinging ip's works, so does pinging domains, they get resolved...
it is clearly not build releated, but i already wasted 2 nights.
maybe someone has any ideas to try. already messed with mtu of wireguard and nat-rules with no success.
thanks in advance.
first thing i'd say is to run 'release' (21.02.1)...
UPGRADEsFLAVOUR="release"
verbage
i'm just not that confident in master at the moment (when it comes to wireguard I also had a failed attempt in the last few days on r17900 but I'm not super familiar with wireguard so was difficult to pin down cause)...
basically at the moment 'stable' means;
the most functional recent master without getting too old
in the RELEASE_NOTES you'll see some comments about potential reported wg issues... which are a good indicator to drop down to 'release' if you require wg, nmap, zerotier...
after you whack on 'release'... then you should probably create a new thread with all the troubleshooting specifics... (the kind of information I posted in the link above)
not sure if I should assign 21.02.1 to everyone on 'stable' although that makes sense in principle given the above issues (if they are proven to be non user-level)...
- users are free to run 'release' at any time...
- alot of people are still getting by on r17900
and current/stable have always been master based... just happens that at the moment... issues are piling up in these...
could be fixed tommorrow but I get the feeling we are likely looking at month/s before master is sufficiently robust across the board... ( have not been able to build it for some time due to wpa-cli missing in action ) (edit: fixed thankyou!)
see: request for help with several issues on master (woohoo this is also now fixed as of r18086)
there is also this: wifi hangs console issue to be aware of for anyone on master using wifi... (edit fixed thankyou! )
there are only 3 key issues i'm aware of on 21.02.1 (not mentioning the packages repo i.e. new or small fixes to packages)
- overlay problem with squashfs (does not effect us)
- auc segfault (does not effect us)
- bootstrap header is aligned left (localfix implemented)
- wifi wont work by default on CM4 WIFI boards (localfix implemented)
- stage2 'out of range' bug (localfix implemented) ( edit: fixed today yay )
- luci docker blk_io_weight bug ( workarounds exist )
- routing repo: naywatch will crash your router
so if you dont install naywatch... all is ok...
1 Like
Thought I'd just add a comment on getting this community build working with the Eir's (Irish ISP) FTTH setup, since it might help other people. There's a few comments earlier on about how the Pi doesn't have the switch fabric, but they seemed to be in the context of LAN connections, not WAN connections. Eir require packets to be tagged on VLAN 10, and their provided VDSL2 modem is also able to take the ethernet feed from the optical network terminal, and handles the VLAN tagging.
Assuming the WAN interface is eth1 (say a USB dongle), then the following steps worked for me:
- Go to Network > Interfaces > Devices
- Add a new device configuration
- Set the type to 802.1q
- Alias it on top of eth1
- Set the VLAN ID to 10
- Save the new device
- Go to Network > Interfaces > Interfaces
- Add a new interface (or edit your existing one)
- Set the type to DHCP client (no need for PPPoE, unlike their DSL offering)
- Use the eth1.10 device (Software VLAN)
- Make sure it's in the WAN firewall zone
- Save
- Repeat new interface steps, but set DHCPv6 client as the type (Eir offer IPv6)
The status of the interfaces should update to show IPs being assigned.
Without the VLAN 10 stuff, and using the base eth1 device, IPs don't get assigned.
Might help someone else with a different ISP that uses the same approach. How you find out your ISP needs VLAN tagging - no idea; I discovered that Eir do this by searching the 'net.
Edit:
Eir headend -> fiber distribution on pole -> termination point in house -> ONT (Huawei of some sort) -> Ethernet cable -> Pi USB dongle (WAN/WAN6) -> Pi (OpenWRT) -> Pi onboard Ethernet (LAN) -> Ubiquiti switch -> home network
2 Likes
why you can't create a bridged connection with FTTH equipment?
Is this limitation forced from the ISP side?
I may have been unclear - that set of steps removes the ISP modem from the equation, and the Pi is talking directly to the optical network terminal. Previously I had to have it inline, with OpenWRT doing PPPoE negotiation, and the modem in bridge mode (since that was FTTC with VDSL from cabinet to modem).
I asked this question because I have heard from people using FTTH that you can't create bridge connection with the fiber equipment because it is not allowed from the ISP side. You can only use DHCP from the FTTH equipment but it creates the issue of double NAT. How to overcome the issue of double NAT?
I am also using FTTC connection VDSL.
As far as I can tell, Eir aren't doing anything that causes double-NAT. I get a /23 and a /56, and OpenWRT passes the /56 through as a /60 for the LAN. If you don't specify VLAN 10 on the WAN ports, you don't get any addresses from Eir.
For FTTC, I had to keep the F3000 (Eir's model number, it's a Sagemcom under the hood and can be broken in hilarious ways) in bridge mode to convert the VDSL to Ethernet, and then configure a WAN interface as PPPoE and send the right secret; I presume the F3000 was doing the VLAN 10 stuff.
When I initially switched to FTTH, I kept the F3000 inline - all that changed in that setup was the VDSL phone line was unplugged, and the ONT ethernet cable was plugged into the WAN port of the F3000. OpenWRT was still doing PPPoE and it all still worked somehow.
1 Like
Yep, the IP ranges assigned to the Pi's public interface line up with what external sites see.
1 Like
If FTTH is passing you public IP addresses then I think it is a bridged connection betweem openwrt and FTTH equipment via VLAN. And what about FTTC what was its setup? You mentioned pppoe, I am also using the same thing but you set it up via specifying VLANS in it? And were you also getting your TV service from it? Via IPTV?
Edit
For my setup I specified no vlans and there are two vlans i think mentioned in my modem and both are in bridged connection and I am able to use both internet and IPTV without specifying any vlans in wan setup.
No TV service. Technically the F3000 also provides me with a VoIP registration (I presume when it's not in bridge mode), but I don't use that either.
No, for the PPPoE configuration I wasn't using VLANs at all - the F3000 was in the path at that point.
Zeroth setup:
DSL headend -> Filtered phone socket -> RJ11 cable -> F3000 (modem mode) -> home network
Stock config 
There's a RPi doing pihole stuff floating around in here, and after getting frustrated with the F3000's inability to change the LAN addressing properly (wrote it up at https://www.cricalix.net/2020/05/28/eir-f3000-fst-5366-pains/, and the post after that), I dropped OpenWRT into the mix.
First setup:
DSL headend -> Filtered phone socket -> RJ11 cable -> F3000 (bridge mode) -> Pi's USB connector (WAN) -> OpenWRT -> Onboard ethernet (LAN)
OpenWRT was configured to use PPPoE for the WAN interface, sending the relevant CHAP secret that's documented pretty well on the 'net. F3000 was doing VDSL -> ethernet conversion. It may or may not have been doing VLAN tagging.
Second setup:
Fiber headend -> termination point -> ONT -> RJ45 cable -> F3000 (bridge mode) -> Pi's USB connector (WAN) -> OpenWRT -> Onboard ethernet (LAN)
Here, all that changed was the input to the F3000. I hadn't changed OpenWRT, and was rather surprised when it all continued to work.
Third setup:
Ripped out the F3000, enabled two aliased VLAN devices on top of the USB dongle, set one to DHCP, one to DHCPv6. No more PPPoE setup (see parent comment for the line diagram).
1 Like
There is DHCP server running on ONT?
I have no idea. It's a black box as far as I'm concerned; it could be it comes up and talks to the head-end and gets a range to hand out. It could also be that it's just a protocol converter, and the DHCP request from the Pi goes all the way back to the ISP's servers.
Packaging for it says it's a HW model HN8M8010TsG02, and the description says OptiXstar HN8010Ts XGS-PON.
1 Like
then I think it might be just optical terminal and not a combination of fiber optic, router and wireless terminal. Just like I have modem router wlan combo but I am just using modem part as bridge and my own pi4 router and my own wireless access points.
I think it is great you are able to use your own router with FTTH.
Is it fine to show your IP address like that?
2 Likes
Yes.
From an IPv4 perspective:
- It's DHCP. If I spoof my MAC and renegotiate the DHCP request to the ISP, I'll end up on a different address range. Heck, might not even need to spoof the MAC.
- It's not like IP addresses are secret. You can nmap the entire internet if you want to (though your ISP might notice) to see what addresses have active hosts. Check out shodan.io if you've not heard of it before.
- OpenWRT's default configuration is 'default deny' on the firewall for packets that originate on the WAN side and land on the WAN interface.
- The IPv4 address is NAT'd anyway, and the internal IPv4 range is RFC1918.
From an IPv6 perspective:
- Similar story for DHCPv6. Change the client ID on the DHCPv6 request, and the ISP will issue a new range - just did that to prove it I'm no longer on '191b'.
- Firewall again. Same rules about WAN => LAN apply. I've got several Linux boxes hanging around on the LAN, with "public" IPv6 addresses, and none are reachable from outside my home network.
- iOS and Windows both have the concept of privacy addresses when it comes to IPv6, and will rotate through IPs unless you configure them not to.
In the current configuration, the worst that could happen is someone decides to DoS my network range. The Pi will probably fall over under the load.
2 Likes
so i've uploaded a /tftpboot 'sample' zip with (draft) config generator...: https://rpi4.wulfy23.info/misc/tftpboot/
came in handy for me over the last day or two messing with a laptop I can't open (easily)...
currently sort of has;
- clonezilla
- debian 11 netboot installer
- gparted
- openwrt x64 initramfs
- some other minor stuff
notes
really only for experts at this stage... but may add some 'per-device' and special network device specific stuff ( cisco / ubiquiti ) in the future...
it's ~ 750M and you'd need twice that to unpack it... so try to keep a local copy of the .tar unless the version number changes...
it's not rpi4 specific so anyone with extroot / x64 / 2G free should be able to use it...
1 Like
I am waiting for the integration of IDS, IPS and DPI tool you mentioned some time ago. I think it was DPI.