Hello All,

I am trying to work out a method to make a general firewall rule that prevents hosts from one network (e.g. ether2) from accessing hosts on the network with the default gateway that does not require advance knowledge of that IP subnet.

Consider a hotspot appliance that has a dhcp client on the internet side. If this is connected to a company LAN, then the LAN hosts become exposed to the public network.

If I knew in advance that a DHCP interface would pick up address 192.168.1.25/25 for example, I could make a firewall rule like

/ip firewall add chain=forward dst-address=192.168.1.0/24 action=drop

Packets destined for addresses beyond the gateway will still work (although won't be able to *ping* the gateway) but comms between the public network and this 'transit' network will be blocked.

What I am looking for is a way to do something general like:

/ip firewall add chain=forward dst-address=<subnet assigned by dhcp-cli-1> action=drop

Any ideas? I'm thinking scripting, but without any idup/ifdown kind of triggers, I'm can't think how to make a script fire up reliably..

Regards, Mike.

out-interface= instead of dst-address=?

Hi!

Thanks for the suggestion.

The problem with that is that when the remote gateway is on that interface, a rule based on outbound interface only will effectively block access to internet as well

Not only that, but will probably prevent even dhcp client from obtaining any address.

I'm thinking it will probably only be possible have to be done using some kind of script technique.

Cheers!

The problem with that is that when the remote gateway is on that interface, a rule based on outbound interface only will effectively block access to internet as well

what gateway do you mean?.. if user talks to its segment - it cannot be filtered by firewall, if it's not wireless =)

Not only that, but will probably prevent even dhcp client from obtaining any address.

local dhcp server is affected by 'output', not 'forward' chain

Goof evening!

[quote="Chupaka"][quote="meverest"]The problem with that is that when the remote gateway is on that interface, a rule based on outbound interface only will effectively block access to internet as well [/quote]
what gateway do you mean?.. if user talks to its segment - it cannot be filtered by firewall, if it's not wireless =)

what we are talking about here is like a wireless hotspot appliance router. The idea is that you plug the thing into some network, call it the private network. The hotspot appliance uses a dhcp client to get an address off that network, and then public access users on the wireless side can log on to the hotspot and access the internet. OK so far.

The problem, though, is that the wireless clients can also potentially access other hosts that are on the private network. What we need is to prevent wireless clients from accessing hosts on the public network but still can get access through the internet gateway on that private network.

If we knew in advance what is the subnet of the private network, we can easily use a forward filter with src-address='wireless network' dst-address='private network' action=drop

But until the device is plugged in and gets a dhcp address, we don't know what the subnet will be.

[quote="meverest"]Not only that, but will probably prevent even dhcp client from obtaining any address.[/quote]
local dhcp server is affected by 'output', not 'forward' chain[/quote]

I was actually thinking about the hotspot dhcp-client device getting address from the private network dhcp server, but good point! the same argument is true - thanks.

Cheers,

Mike.

Greetings!

Can you use something like this? This presumes the hotspot is on ether2 and your localnet is on ether3 with 10.0.0.0/24 subnet. Still allows access to ether1 (internet interface).

/ip firewall filter
add chain=forward in-interface=ether2 out-interface=ether3 action=drop
or
add chain=forward in-interface=ether2 dst-address=10.0.0.0/24 action=drop

G'day Tim!

[quote="SurferTim"]
/ip firewall filter
add chain=forward in-interface=ether2 out-interface=ether3 action=drop
or
add chain=forward in-interface=ether2 dst-address=10.0.0.0/24 action=drop[/quote]

I /could/ do that, in fact that is exactly what I do at the moment with 433 boards. BUT my current project is to build a low cost hotspot appliance based on RB/411 or RB/CRD - which only has a single ethernet port.

I am playing with scripts at the moment, something like:

:global network [/ip address get [/ip address find interface=ether1] network]
:global mask [/ip address get [/ip address find interface=ether1] netmask]
/ip firewall filter add chain=forward dst-address=($network."/".$mask) action=drop

which is kind of OK, but this:

[/ip address get [/ip address find interface=ether1] netmask]

results in blank in v3.20 - not sure if that is by design or a bug. I'm having a go to see what can be done when just specifying "/24" for the mask, but need to work out how to fix it so I can run the script every 60 sec or so without filing up the firewall with duplicate rules!

I'm also thinking about trying to do something with ARP table - maybe ad firewall rules when they appear in arp, or perhaps add them to an address list and make a firewall rul to drop packets destined for that list....

A few ideas, but not sure how it will all end up.

Cheers!

Back again,

this is where I am at so far. I can run these two scripts every 60 seconds or thereabaouts:

:foreach addr in [/ip firewall address-list find list=protected-LAN] do={/ip firewall address-list remove $addr}
:foreach addr in [/ip arp find interface=ether1] do={:put [/ip arp get $addr address];/ip firewall address-list add list=protected-LAN address=[/ip arp get $addr address]}

The idea, of course, is to watch the arp table on the ethernet interface and add to an address list when they show up. I remove them all first, so that I don't end up with lots of duplicates.

Perhaps it would be better to first test whether an address is already in the list, but I haven't made it that far yet.

Besides that, address lists are persistent, so we need to remove them in case the device is taken to some other location one day. Maybe one day we will be able to add a timer (like mangle rules) from the shell, but until then, this is the only way I can think of removing them.

Cheers!

if you want use the same ip pool in private net and wireless net - just add a rule in firewall like this:

in-interface=firewall out-interface=private dst-address=your_ips action=drop

don't use script for firewalling =)

Good Morning!

[quote="Chupaka"]if you want use the same ip pool in private net and wireless net - just add a rule in firewall like this:
[/quote]

Well, sure.. I could do that, but I don;t know what the IP addresses are in advance! ;-)

[quote="Chupaka"]
don't use script for firewalling =)
[/quote]

why not? Mt sript solution is the only workable solution I have been able to implement so far.

Cheers.

Well, sure.. I could do that, but I don;t know what the IP addresses are in advance!

you don't know, what addresses you use?.. how can it be? =)

I don't understand you... can you please give me an example, why that last rule will work not as expected?

Good evening,

[quote="Chupaka"]
you don't know, what addresses you use?.. how can it be? =)
[/quote]

Because it is a dhcp server - I don't own the dhcp server, I don't own the network, and I don't know who it will be or where it is.

[quote="Chupaka"]
I don't understand you... can you please give me an example, why that last rule will work not as expected?
[/quote]

Imagine 100 units of RB/CRD in cases sitting on a shelf. Some customer comes along and buys one, takes it home and plugs it in.

I need to pre-configure those 100 units so that each one will work in the same way - and to protect the customer's LAN when they allow public access users to connect to the wireless.

no sweat - the scripting technique I worked out will do the job for the time being. If a future version can do something like fire a script when the arp table gets a new entry, then it will be better. But for the moment, this one will do.

Cheers!