I'm attempting to make it so one on prem server on our internal network can only send and receive traffic from several specific ip addresses (all nodes in our cloud infrastructure). There's no reason this host should ever need to talk to anything else.
I've created the following firewall rules, in /etc/config/firewall, and put the just above the forwarding rule (as I understand the rules are parsed sequentially).
config rule
option name 'Accept Database Server'
option src 'lan'
option src_ip '192.168.24.200'
option src_mac '28:F6:C9:A6:13:3E'
option dest 'wan'
option dest_ip 'X.X.X.X'
option target 'ACCEPT'
config rule
option name 'Accept Redis Server'
option src 'lan'
option src_ip '192.168.24.200'
option src_mac '28:F6:C9:A6:13:3E'
option dest 'wan'
option dest_ip 'Y.Y.Y.Y'
option target 'ACCEPT'
config rule
option name 'Accept Code Host'
option src 'lan'
option src_ip '192.168.24.200'
option src_mac '28:F6:C9:A6:13:3E'
option dest 'wan'
option dest_ip 'Z.Z.Z.Z'
option target 'ACCEPT'
config rule
option name 'Block All'
option src 'lan'
option src_ip '192.168.24.200'
option src_mac '28:F6:C9:A6:13:3E'
option dest 'wan'
option target 'REJECT'
After restarting the firewall, the host still unblocked and can access the general internet. Am I missing something? Or putting something in the wrong place?
Also, is there a way to condense the first three rules into one rule?
Thanks very much.
Take out the MAC addresses and then restart the firewall.
Does that fix the issue? If not, let's see your complete firewall file.
Also, just to make sure... the destination IPs are all on the internet, correct?
Taking out the Mac addresses changed nothing. I made the change and ran "service restart firewall"
Then on 192.168.24.200 I am able to ping and wget forum.openwrt.org. . . so, no dice.
Yes, those IPs are all in our AWS cloud.
Full /etc/config/firewall (with public ips redacted) follows:
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config rule
option name 'Accept Database Server'
option src 'lan'
option src_ip '192.168.24.200'
option dest 'wan'
option dest_ip 'X.X.X.X'
option target 'ACCEPT'
config rule
option name 'Accept Redis Server'
option src 'lan'
option src_ip '192.168.24.200'
option dest 'wan'
option dest_ip 'Y.Y.Y.Y'
option target 'ACCEPT'
config rule
option name 'Accept Code Host'
option src 'lan'
option src_ip '192.168.24.200
option dest 'wan'
option dest_ip 'Z.Z.Z.Z'
option target 'ACCEPT'
config rule
option name 'Block All'
option src 'lan'
option src_ip '192.168.24.200
option dest 'wan'
option target 'REJECT'
config forwarding
option src 'lan'
option dest 'wan'
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'
config include
option path '/etc/firewall.user'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'SSH-for-Etheria'
list proto 'tcp'
option src 'wan'
option src_dport '2222'
option dest_ip '192.168.24.24'
option dest_port '22'
I don't think this will make a difference, but worth a quick try:
/etc/init.d/firewall restart
I am noticing something here... the closing quote is missing for this line as well as the corresponding one in the block rule.
3 Likes
Re missing ' : I must have deleted it while looking for public ips that needed redacting. It's present in my actual file.
Running it from /etc/init.d/firewall restart made no difference (I did it both ways throughout my troubleshooting saga).
Does your device at 192.168.24.200 have any other network interfaces? wifi or a second network card (or VLANs)? or are you running VMs on that host that could have a different IP address on the LAN?
Does your device at 192.168.24.200 have any other network interfaces? ... VLANS?
Nope.
Running VMS
Nope. This host is an old tower running Ubuntu on bare metal. It does some data analysis thing someone wrote in Lua. It does process and store some sensitive data, which is why there's a concern.
Ok... I was just asking to make sure that there couldn't be another route to the internet (i.e. another IP/network).
Silly question... is the IP of that machine what you expect (192.168.24.200)? I'm simply trying to rule out any typos or misread/misremembered addresses (it happens to all of us)... not insinuating anything, but just worth a double check 
lol, no offence taken! I'd be grateful and chagrined to discover it's some oversight like that. But it's not (at least not that). The ip is static, and I've triple checked it. And it it wasn't 192.168.24.200, I'd be hearing from devs that they couldn't reach the analytics server.
Two ideas to consider trying:
-
remove/disable the outbound accept rules for that host so that the only rule in place is reject. In theory, this should mean that the host will be unable to reach anything on the internet. If it still can reach stuff, something is wrong with the rule itself (although I have to say, it looks fine).
-
create the same type of rules and apply them to a different host... this way you can test/tinker without affecting a critical system (for example, if that system must be able to reach the permitted IPs and cannot be interrupted, you probably don't want to do the first suggestion, but you could do it on an alternate host).
Other thoughts...
On the reject rule, you could simply have it crafted like this:
This should have the same effect but basically says that anything coming in on any zone from that IP to any zone gets dropped. It won't affect LAN traffic since that is switched, not routed. And obviously the rules above should still allow the host to reach the desired cloud IPs.
1 Like
I did as you suggested, leaving only the shortened rule you suggested and the host is still not blocked. So. . . that rule is not being applied (or not being applied correctly). Curious.
As an experiment I blocked another host. Same behaviour. For whatever reason, the firewall is not applying my rules (or not applying them correctly). Any further debugging suggestions there?
Good to know I made my file correctly anyway. When it wasn't working, I'd assumed I'd made some kind of configuration mistake.
Is there anything in here?
What version of OpenWrt are you running?
ubus call system board
/etc/firewall.user
An empty filre. It had stuff in it (that I put there) earlier when I started this saga, but that stuff didn't work and it's gone now.
root@OpenWrt:~# ubus call system board
{
"kernel": "5.4.179",
"hostname": "OpenWrt",
"system": "MediaTek MT7621 ver:1 eco:3",
"model": "Netgear R6220",
"board_name": "netgear,r6220",
"release": {
"distribution": "OpenWrt",
"version": "21.02.2",
"revision": "r16495-bf0c965af0",
"target": "ramips/mt7621",
"description": "OpenWrt 21.02.2 r16495-bf0c965af0"
}
}
I'm baffled....
Let's review your network config file.
And, on the .200 host, let's see what you get from the following
route
traceroute openwrt.org
route and traceroute look as expected.
route
Destination Gateway Genmask Flags Metric Ref Use Iface
default OpenWrt.lan 0.0.0.0 UG 0 0 0 enp1s0
192.168.24.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0
traceroute (First two hops):
1 OpenWrt.lan (192.168.24.1) 0.363 ms 0.300 ms 0.373 ms
2 10.1.10.1 (10.1.10.1) 1.857 ms 1.987 ms 2.252 ms
/etc/config/network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fd0c:5162:e608::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.24.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
Thank you so much for all your help!
Could IPv6 be playing a part here. Seems unlikely (given the IPv4 information in your previous post), but what if you explicitly disable IPv6?
I thought of that too (but figured. . . nah). Anyway, I just went through and disabled ipv6 in Luci and took out every reference to it in the firewall config. No dice.
`Have you installed any non-default packages or upgraded any of the packages?
I think I figured it out...
add this
list proto 'all'
Meanwhile, it appears that pings are possible without the above addition, but I don't think you can connect with TCP or UDP to any services on the internet. But I think this should solve the problem. Let me know how it goes.