When I put my ISP modem/router in bridge mode, my Raspberry Pi 4b is not getting a WAN ip address.(ipv4 and ipv6)
(everthing is working fine if the modem is in router mode (double nat, the reason I want it in bridgemode offcourse)
When I connect my wrt3200acm or my laptop directly to my bridged modem it's getting a (wan) ip address. So It looks like it's a problem from my Pi setup.
My Pi is using only one port connected to a manageable switch (TL-SG108E) In this setup and without bridge mode it is working fine. (it get's an ipv4 and ipv6 ip address) Does it have to do something with the switch/vlan setup maybe?
I'm using a Raspberry Pi 4 Model B Rev 1.2 with OpenWrt 21.02.1 r16325-88151b8303 / LuCI openwrt-21.02 branch git-22.025.79177-4ec18ec
This may be your issue. This particular switch is a terrible option for your application for 2 reasons:
You cannot set the management interface/VLAN from which it gets its IP address if it is set to obtain an IP via DHCP (more about this later).
The switch's administrative interface will respond on all VLANs because, again, you cannot set the management VLAN. This includes potentially responding on the WAN.
On the first point, if the switch is set to get an IP via DHCP, it may be obtaining an address from your ISP, and thus not allowing you to get an IP on your Pi.
On the second point, if your switch has an IP in your management LAN, this is theoretically less of a vulnerability because it will only respond to requests to that address (but it will respond, even if the request comes from another network). The reason this may be less of an immediate concern is that your ISP should (in theory) not allow any routing of RFC1918 addresses (assuming you are issued a proper public IP in the first place). However, the security ramifications here are significant as the switch does not have adequate protections, and it is possible a bad actor on the internet could compromise your network.
This switch isn't great, but it is okay for use inside your network (i.e. behind your router/firewall).
There are 3 options to help address the problem:
set the IP address of the switch manually (static IP) and do not use DHCP.
get a second ethernet interface for your Pi (the UE300 is really popular for this pupose). This way your WAN can be physically isolated from your LAN(s) and it will not need to go through that switch.
purchase a different switch. The TP-Link TL-SG1xxE series is the only one that I know of that has this really poorly designed management firmware. Almost any other managed switch should be better than this (including the low end Netgear, DLink, and others).
I'd recommend #2 as the best solution. #1 is obviously the cheapest. And #3 is worth considering, but if security within your network (behind your router/firewall) isn't a huge concern, there may not be a need to replace the switch.
If you were using the switch as an unmanaged device (i.e. all on ports on the one untagged network), that would actually be the root of your issue. For your setup, you must configure VLANs on the switch and the Pi.
However, everything I said earlier about this switch still stands, and the UE300 is the better option for your physical configuration.
As far as 16 port switches -- there are tons. You need to select one based on your specific needs: Do you need it to be managed (i.e. VLAN capable)? do you need any advanced management features, or is basic VLAN sufficient? What about PoE? If PoE, how many ports? What PoE standard(s)? What total power budget? And form factor (desktop/wall mount/rack mount)?
If you have the loop detection enabled then it will send out loop detection packets on all ports, and the modem will lock to the MAC address of the switch and refuse to respond to your RPi's mac address.
using the UE300 is the best option, if you need to use the switch do several things:
Turn off loop detection
put the switch in static IP mode with a static IP on your internal network range, but preferably not the 192.168.0.1 or 192.168.1.1 range (make the "attackers" guess more)
Set a cryptographically strong password, like one generated by keepassxc or similar strong password keeper app. I'd suggest 12 characters random upper/lower/numbers
Follow the "modem dance". Turn off modem, disconnect ethernet cord. Turn on modem, wait for it to boot. Reconnect ethernet cord... It should lock to the MAC of the first thing it hears, which should be your RPi4 if the VLANs are set up correctly and no loopback detection.
I personally think with a non-standard non-public IP on the switch, and a cryptographically strong password, the security is probably not worth worrying about. Compromising the switch would require someone to compromise the ISP modem and then from the modem the switch... or compromise your router first and then the switch... With a crypto-strong password most compromises are unlikely.
I did disable the loop detection as you suggested. I wil give it try somewhere this week.
On thing is keeping me busy.. When the modem of my ISP is in routermode, the RPi is getting an IP as it should be. But when I put in bridge mode is doesn't. (and a single connected device does) So maybe it's a combined problem?
This is to be expected due to how DOCSIS provisioning works. In bridge mode modem will only provision a few MACs with IP addresses (often just a single one) and often only for a limited time window. If any device first gets noticed by the modem that single slot can be assigned already when your router gets around to ask the modem. ISPs could configure modems to allow more than one MAC address, but apparently rarely do so. DOCSIS provisioning is quite an elaborate dance
In router mode that is different as the modem-routers DHCP server will allow many more that 1 devices and will also do so as long as the router is running (modulo any bugs).