Instead of scanning your public address from a host inside your network, try scanning your public address from a host external to your network. I can recommend both grc.com's ShieldsUP! and pentest-tools.com's Online Port Scanner.
I supppose you tried to access the public IP of the router from a host inside the lan, which is not the same as accessing the router from the internet.
In any case post the following to verify:
uci export firewall; iptables-save -c
Ah right. I will try this. Thank you.
There isn't any port open on the wan.
By default uhttpd is listening on tcp 80 and 443 ports on all IP addresses of your router, you can check with command:
netstat -lpn | grep uhttpd command.
You should see similar output:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1818/uhttpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1818/uhttpd tcp 0 0 :::80 :::* LISTEN 1818/uhttpd tcp 0 0 :::443 :::* LISTEN 1818/uhttpd
It doesn't mean that your ports are opened from the WAN, because the IP address of the wan port is the part of your device (openWRT router) and isn't part of the zone WAN.
Thank you for that. I understand now at a high level that when a client on LAN connects to the public IP address of the router, it actually access the router differently from another device on the WAN zone.
Thanks for that, it is quite interesting for a newbie in networking like me
Let me make sure I understand this correctly :
- A router has 2 IPv4 and 2IPv6 addresses :
a) 1 IPv4 + 1 IPv6 address for the WAN port. These IPv4 and IPv6 address are often called "public IP".
b) 1 IPv4 + 1 IPv6 address for the set of all LAN ports that are present in the router.
- When you say "Zone WAN" are you talking about the zone of the firewall
fw3configuration? If yes, then I am a little unclear why you say the IP of WAN port is not part of the WAN zone, because the WAN zone is configurable, and so this IP could be part of it. So I am guessing you mean a slightly different thing, can you explain?
- when a client on the LAN hits the router from the LAN ports, trying to access the public IP, it accesses it from the LAN IP, for which the firewall rules are more laxed than the WAN port. Therefore it sees port 80 open, whereas another machine on the WAN port would be blocked on that port.
Sorry, this is very basic I realize, but I want to make sure I am not making a mistake in my fundamental understanding. Thanks!
Dear @SharkScout ,
It isn't true. You can check the number of IP addresses of your router with command:
You will see all of them and you can recognize that you have got - at least - 2 more addresses for interface loopback (by default they are 127.0.0.1 and ::1/128).
Generally yes. Be noted, these addresses provided by your ISP (Internet Service Provider) and your router got it via DHCP protocol.
It is true if your LAN ports (and maybe wlan ports as well) are bridged together into 1 interface.
Sorry, it can be misunderstand-able. It isn't part of the zone from (firewall) traffic (source/destination) point of view. It wasn't simple to understand this for me as well.
Maybe it is more visible, if you check your default firewall rules in Luci (Network/Firewall/Traffic Rules, for example "Allow-Ping"). You will see that the source is wan (zone) and the destination is the device itself (and NOT the zone WAN).
Yes, because - in this case - another (default general setting is playing, which allows the forwarding from zone LAN to zone WAN. (You can see on Luci/Network/Firewall/General Settings/Zone.)
Maybe this guide can also help you to understand the logic of the firewall. (If my explanation isn't enough clear.)
Hopefully I could help a little bit.
Thanks a lot for that, that's very helpful!
I check the allow-ping rule as you suggested.
When I do it on the CLI, it's pretty clear:
firewall.@rule=rule firewall.@rule.name='Allow-Ping' firewall.@rule.src='wan' firewall.@rule.proto='icmp' firewall.@rule.icmp_type='echo-request' firewall.@rule.family='ipv4' firewall.@rule.target='ACCEPT'
But there is no destination there, so I read the documentation you pointed out :
srcis given, the rule matches incoming traffic
I assume that's what you meant by the destination is the device.
If I check it in Luci (which is actually what you suggested) I see this:
I am a little unclear on the interpretation of that, since in and out are * and source and destination are ips 0.0.0.0.0/0, so seems unassigned?
"In" and "Out" fields are for incoming and outgoing interfaces.
"Source" and "Destination" fields are for IP addresses.
"0.0.0.0" and mask "/0" means assigned to all IPs. (As you can saw in the output of netstat command for port 80/443 in my first comment.) In other words, the rule will match independently from the IP addresses and its masks.
Ok, that makes sense. So that means any device on the WAN can ping any device on my LAN, including my router. That's probably wrong for my use case, as I do not have a need for my LAN device to be exposed.
@vgaetera thank you for these links. I will go through them attentively.
Not necessarily. You can test this yourself.
If your LAN uses RFC 1918 (private) addresses (10/8, 172.16/12, 192.168/16), then LAN addresses will not be accessible from the WAN. Private addresses are not permitted on the public Internet, so they can't be reached directly.
Ah right. Thank you.
Hmm, I feel things are not completely clear to me yet.
Why does this line in CLI
translates to this in LuCI?
source = 0.0.0.0/0
And why does the absence of destination also translates to
destination = 0.0.0.0/0
in LuCi, even though the documentation says :
srcis given, the rule matches incoming traffic
Given what the documentation says, I thought the destination address would be the IP of the WAN port of the router.
What am I missing?
A recognition of how OpenWRT translates the principles into practical configuration. This will come with time and experience.
firewall.@rule.src='wan' refers to the source zone, not the source address.
source = 0.0.0.0/0 is implicitly derived from the absence of a specific source address. In other words, if a specific source address isn't defined, then assume all possible addresses are included in the rule.
Same reason. No explicit definition of a specific address = implicit assumption of all possible addresses.
src is, as noted above, the source zone. All traffic which arrives at a firewall from any zone is, by definition, incoming.
The corresponding definition, outgoing, refers to all traffic which leaves the firewall.
Any outbound traffic from your LAN to the Internet is incoming from the LAN to the firewall, and outgoing from the firewall to the Internet.
Any inbound traffic from the Internet to your LAN is incoming from the Internet to the firewall, and outgoing from the firewall to the LAN.
Ah, I understand. What LuCi calls
Source corresponds to
src_ip on the CLI, and not
Thanks a lot for your detailed explanation.
Yeah, the correlation between CLI and GUI could be... better.
Haha, no problem, I just need to learn.
Very interesting links. I understand that OpenWrt is based on the weak host model.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.