I have several vlans, each within its own firewall zone. I want to allow DNS and DHCP traffic from every vlan to the router, but since it's tedious to create a firewall rule for each zone I want to create a single rule with Any zone as source zone and Device as destination zone for ports 53 and 67. The problem is this would also include traffic from the WAN zone. Would this pose a security risk? What consequences could result?
Other than the fact you don't likely need the DHCP or DNS from WAN (your router talks to it, usually not LAN clients), you're blanketing opening ports. Next, if requests come from LAN clients or the OpenWrt, the corresponding replies are allowed by default anyway (i.e. the LAN to WAN forwarding rule).
Also, there's already a default rule for OpenWrt to receive DHCP replies from WAN.
Making a DNS rule would do nothing except put you at undue risk.
Serving DHCP/ DNS to WAN is indeed considered dangerous and might cause you being blocked by your ISP, as these rogue DNS servers can cause real harm to the internet at large in DNS amplification attacks and likewise the DHCP functionality may cause even more harm to other ISP customers in the same subnet. Aside from this, dnsmasq isn't meant to be accessible from the internet and might cause harm to your very own security and reliability of service as well (it's rather easy to DoS your device by forcing many tcp connections from dnsmasq and thereby making it fork excessively, leading to OoM).
tl;dr: don't do that, ever.
2 Likes
What do you mean by "blanketing opening ports"? I need to allow traffic for ports 53 and 67 from all the vlans to the router otherwise clients would not be able to get an IP and would have no DNS resoultion.
Since you don't show the rule; and what you describe already exists by default, I can't imagine what else you're opening.
I answered from a security perspective.
Does your ISP issue your connection multiple Public IPs or something?
If so, this would be a special use case; and wasn't made clear in the OP. I'd understand if this happens to be your case. Otherwise, I'd consider @slh's caution.
Otherwise your OpenWrt should issue Private IPs that will NAT and connect clients to WAN thru its single ISP-assigned IP (which a default rule already exists to get the DHCP reply for the WAN). The dnsmasq software in OpenWrt will make the DNS requests and forward them to clients.
1 Like
There is no such rule by defaults. These are the default rules after a fresh install:
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled '0'
This is an example vlan firewall zone setup:
config zone
option name 'vlan'
option output 'ACCEPT'
list network 'vlan'
option input 'DROP'
option forward 'DROP'
This is the rule I created for DNS and DHCP to work for this vlan:
config rule
list proto 'udp'
option src 'vlan'
option dest_port '53 67'
option target 'ACCEPT'
option name 'vlan DNS DHCP'
Since there are several firewall zones for several vlans I would have to create several identical rules for all of them. What I wanted to do was to create a catch-all rule such as
config rule
list proto 'udp'
option src '*'
option dest_port '53 67'
option target 'ACCEPT'
option name 'all vlans DNS DHCP'
but as @slh said it would be dangerous. Maybe I could add an exception rule such as
config rule
list proto 'udp'
option src 'wan'
option dest_port '53 67'
option target 'REJECT'
option name 'reject wan DNS DHCP'
but I'm not sure if I would need to put it before (up) or after (down) the catch-all rule.
Hope this clears things up. Is this what you wanted me to post?
How many VLANs are you talking about here? If it's only a few (~5 or so), it is quite likely the discussion itself is more effort than adding the individual rules.
If you have a fairly large number of VLANs making individual rules impractical, can any of the VLANs use the same firewall zone? If the rules are largely the same on two or more of the zones, you can often put them together into a single zone. If you wish to restrict inter-VLAN connections, simply set the zone-level forward rule to reject.
4 Likes
It's not a question of effort, I want to understand the thing. And I also want order, if I can create one rule instead of 10 I want to do it that way.
it seemed to be...
1 Like
well, it's not. do you have any technical input?
Yes. I gave you some before. And I agree that it is a bad idea to open these services it to all zones.
1 Like
Would the rule
config rule
list proto 'udp'
option src 'wan'
option dest_port '53 67'
option target 'REJECT'
option name 'reject wan DNS DHCP'
address the issue with the catch-all rule?
Yes, that rule will work if it is placed above the other rule.
1 Like
It does exist, unless you have some special use case, the only one I could guess is:
I also explained how DNS works. Rules allowing such traffic are unnecessary as they originate from LAN, and that and the return traffic allowed by default; or go to the OpenWrt - and then are asked/answered by the router and reply returned to the client. So again, I guess I don't understand your use case, and you didn't explain. My bad. The VLAN description didn't cover if this was some Public IP space or something.
Usually ISPs don't allow customers to let clients get multiple Public IPs via DHCP - but that seems like what you're describing. Can you clarify this?
EDIT:
- Are you sure you're not trying to accept DHCP from the OpenWrt (i.e. the Private IPs issued from the OpenWrt that I mentioned)?
- Have you allowed general traffic from the VLANs to WAN (as this would cover DNS and its replies)?
- Allowing INPUT to the OpenWrt would cover DNS requests made to the device itself
- These things can be done en masse by placing the interfaces into a Firewall Zone having such rules
Without advanced configs, DHCP doesn't cross networks (it's a Layer 2 provisioning mechanism) - so "DHCP traffic from WAN" doesn't normally work anyway
Making this setup in Luci I surely agree to the non efficiency thoughts, especially every time you upgrade OpenWrt.
But making these rules by copy paste and adjust in config file or even better by script (when upgrading OpenWRT a script setup is a good idea)…well this tread has gone on for two days now.
But you could actually just set all the LAN zone’s Input rules to accept. But then everyone on the internal network will be able to log in to luci and dropbear.
1 Like
As you can see from what I posted
config zone
option name 'vlan'
option output 'ACCEPT'
list network 'vlan'
option input 'DROP'
option forward 'DROP'
input is not allowed. I understand you are saying clients can be set up to use specific DNS servers, but unless I manually configure this per-client, normally clients get DNS services from DHCP and treat the router as their DNS server. I can assure you there is no DNS resolution on the clients if I don't allow traffic to the router for port 53.
The issues you are talking about seem to be advanced configurations which I did not set up.
The issue has been up for just a few hours actually.
Yes I want the vlans to be isolated, they don't have to see the router or other devices. I created several because I don't want the devices to see each other too. This is why what @psherman told me to do doesn't seem to be enough.
Please explain what you are experiencing when you put the VLANs into a common zone with the zone forwarding set to drop (or reject). This should isolate the networks… If not, something else is wrong.
1 Like
VLAN is always isolated from each other by design, firewall has nothing to do with this.
But the firewall settings can’t isolate clients in the same vlan. All devices on the same vlan/(interface) will see each other no matter the zone settings.
The firewall can only handle inter zone communication and communication between interfaces in the same zone.
1 Like