Hi,
I am new to OpenWRT. I can't find any installation or configuration documentation for bcp38. Please can you point me in the right direction?
Many thanks,
Chris.
1 Like
If I remember correctly, there is a package called bcp38 or similar...
3 Likes
I have installed bcp38 and also luci-app-bcp38 through luci. However, I can't find any bcp38 interface!
network->firewall->bcp38
3 Likes
Perfect! Thanks.
Chris.
I like your idea, but it's probably better to update the post to rely entirely on the firewall config:
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_config_ipset
1 Like
I previous had to load 400+ firewall rules/subnets. Needless to say, I had to migrate them to ipset instead.
But yes, this is a small list of subnets and iptables could be used.
1 Like
It looks like you misunderstood me. 
I am not against IP sets and their use is perfectly justified for the current task.
What I mean is that it is best to define the IP set for BCP38 in the same firewall configuration using the UCI syntax.
1 Like
Sorry for the silly question, but I can't find a straightforward answer.
The bcp38 should be configured on
the lan, the bridge-lan, the wan?
By logic I'd say on the wan interface but...
Can anybody clarify this point a bit?
Thank you.
BCP38 is meant to filter out packets on WAN with an IP address that can only be used in a LAN. You should configure it on a WAN interface with a public IP address, and never on a LAN interface with a private IP address.
3 Likes
Does your network topology justify the use of bcp38?
The usual home scenario with NAT of private IPs doesn't need it.
1 Like
In that case, in which scenario it should be used?
where you route ( not NAT ) public prefixes...
it's like the mailman putting letters in your mailbox for 'darkman'... you wouldn't open it... with NAT... you wont open anything(forward/accept) that wasn't first requested... and it's highly unlikely your router would have knowledge/ability to forward to unknown public prefixes ( darkman lives in granny flat out the back )
96% chance your providers bgp edges already operate such features anyway...
3 Likes
I did some tests using CAIDA software at different moments of luci-app-bcp38:
Before installing it: https://spoofer.caida.org/report.php?sessionid=1198440
After: https://spoofer.caida.org/report.php?sessionid=1198445
The configs:
I can't see any difference between both tests.
Am I doing anything wrong?
If I read that detailed path output right, you seem to be inside double NAT...
Apparently your ISP uses 10.27.x.x ???
That prevents BCP38 from working, as "your upstream" is still a NAT, so you can't really use BCP38.
Summary:
Test run at: 2021-08-17 15:47:45 GMT
Client Prefix (v4): 84.90.195.x/24
IP | Autonomous System
-- | --
Path 1 (to: 78.41.116.2)
192.168.20.1 | 0
10.27.0.1 | 0
84.91.1.221 | 13156
80.231.159.45 | 6453
I'm having on my WAN interface a public addressable IP address, provided by DHCP, on this range: 84.90.195.x/24 with its provided gateway IP address also being on that range.
That 10.27.0.1 is maybe an HFC-to-fiber gateway somewhere between my installation and the remote ISP central infrastructure.
Being applied in the firewall the rules to drop any in or out traffic with LAN IP addresses:
I can't see why is still not working. 
I think that the incoming DHCP public address does not matter, if in reality the outgoing traffic is routed via double NAT.
Yeah, so the outgoing packets need to have NAT source address and routing to upstream NAT.
Likely the route to 10.27.x.x is visible also in your routing table. ????
You can try removing the option "auto-detect upstream", so that no exception for 10.27.x.x is added to the ipset.
Then likely your connectivity stops (as you apparently route the outgoing traffic to 10.27.x.x")
