I have an AP (WLAN) on one interface and LAN on another and I want to limit access between the WLAN and LAN. I've been using firewall rules to do that but it's getting cumbersome since I often have to duplicate rules for the LAN and WLAN.
I'm wondering if bridging WLAN and LAN and using the bridge firewall rules would be a better and simpler way of restricting access. Then I could reference the bridge in the IP Firewall rather than each duplicate some of the rules for each interface. Any advantages/disadvantages of acting on the link layer and best practices for this in general?
Many thanks.
Re: Best Practioe for Limiting LAN Access from WLAN
Bridging would pretty much open things up further.
Post your firewall configuration and network topology.
Post your firewall configuration and network topology.
Re: Best Practioe for Limiting LAN Access from WLAN
Pretty straightforward network setup. Used for home.
RB450G
Interface 1 - WAN - Cable Modem
Interface 2 - DMZ
Interface 3 - WLAN - external AP running DD-WRT
Interface 4 - LAN (slave to interface 5)
Interface 5 - LAN
Not sure I want to bore you with a ton of rules but it's basically the Dmitry on Firewallinghttp://wiki.mikrotik.com/wiki/Dmitry_on_firewalling setup with some additional rules for viruses. So connections get marked first, everything is proxied.
PIM & IGMP on the LAN and WLAN interfaces with the RB450G as the RP.
Here are some rule snippets to give you an idea of what I'm doing. I've removed some of the filtering between WLAN and LAN in this example. I was thinking that one of the advantages of the bridge would be that Bonjour and multicast/broadcast would get passed by default and that something I've been struggling with.
RB450G
Interface 1 - WAN - Cable Modem
Interface 2 - DMZ
Interface 3 - WLAN - external AP running DD-WRT
Interface 4 - LAN (slave to interface 5)
Interface 5 - LAN
Not sure I want to bore you with a ton of rules but it's basically the Dmitry on Firewallinghttp://wiki.mikrotik.com/wiki/Dmitry_on_firewalling setup with some additional rules for viruses. So connections get marked first, everything is proxied.
PIM & IGMP on the LAN and WLAN interfaces with the RB450G as the RP.
Here are some rule snippets to give you an idea of what I'm doing. I've removed some of the filtering between WLAN and LAN in this example. I was thinking that one of the advantages of the bridge would be that Bonjour and multicast/broadcast would get passed by default and that something I've been struggling with.
Code: Select all
add action=accept chain=forward comment="Allow all traffic FROM wired to wireless network" disabled=no in-interface=ether5_lan out-interface=ether3_wifi
add action=accept chain=forward comment="Allow traffic between wired and wireless networks" disabled=no in-interface=ether3_wifi out-interface=ether5_lan
add action=jump chain=sanity-check comment="Drop illegal destination addresses" disabled=no dst-address-list=illegal-addr dst-address-type=!local in-interface=ether5_lan jump-target=drop_sanity
add action=jump chain=sanity-check comment="Drop illegal destination addresses" disabled=no dst-address-list=illegal-addr dst-address-type=!local in-interface=ether3_wifi jump-target=drop_sanity
add action=jump chain=sanity-check comment="Drop everything that goes from local interface but not from local address" disabled=no in-interface=ether5_lan jump-target=drop_sanity src-address-list=!local-addr
add action=jump chain=sanity-check comment="Drop everything that goes from local interface but not from local address" disabled=no in-interface=ether3_wifi jump-target=drop_sanity src-address-list=!local-addr
add action=jump chain=input comment="DHCP protocol would not pass sanity checking, so enabling it explicitly before other checks" disabled=no dst-port=67 in-interface=ether5_lan jump-target=dhcp protocol=udp src-port=68
add action=jump chain=input comment="DHCP protocol would not pass sanity checking, so enabling it explicitly before other checks" disabled=no dst-port=67 in-interface=ether3_wifi jump-target=dhcp protocol=udp src-port=68
add action=accept chain=input comment="" disabled=no dst-address-type=broadcast,multicast in-interface=ether3_wifi protocol=igmp
add action=accept chain=input comment="" disabled=no dst-address-type=broadcast,multicast in-interface=ether5_lan protocol=igmp
add action=accept chain=input comment="" disabled=no dst-address-type=broadcast,multicast in-interface=ether3_wifi protocol=udp
add action=accept chain=input comment="" disabled=no dst-address-type=broadcast,multicast in-interface=ether5_lan protocol=udp
add action=jump chain=input comment="Allowing some services to be accessible from the local network" disabled=no in-interface=ether5_lan jump-target=local-services
add action=jump chain=input comment="Allowing some services to be accessible from the wifi network" disabled=no in-interface=ether3_wifi jump-target=wifi-services
add action=jump chain=input comment="Allowing some services to be accessible from the Internet" disabled=no in-interface=ether1_wan jump-target=public-services
add action=accept chain=local-services comment="SSH (22/TCP)" connection-mark=ssh disabled=no
add action=accept chain=local-services comment=DNS connection-mark=dns disabled=no
add action=accept chain=local-services comment="HTTP Proxy " connection-mark=proxy disabled=no
add action=accept chain=local-services comment="Allow vista icm udp to 3947 so the logs don't get filled" connection-mark=vista_icm disabled=no
add action=accept chain=local-services comment="Accept NTP/123" connection-mark=ntp disabled=no
add action=accept chain=local-services comment="Winbox (8291/TCP)" connection-mark=winbox disabled=no
add action=accept chain=local-services comment="accept mikrotik dude " connection-mark=dude disabled=no
add action=jump chain=local-services comment="drop all other local services" disabled=no jump-target=drop_local_services
add action=accept chain=wifi-services comment="SSH (22/TCP)" connection-mark=ssh disabled=yes
add action=accept chain=wifi-services comment="Accept NTP/123" connection-mark=ntp disabled=no
add action=accept chain=wifi-services comment=DNS connection-mark=dns disabled=no
add action=accept chain=wifi-services comment="HTTP Proxy " connection-mark=proxy disabled=no
add action=accept chain=wifi-services comment="Accept EoIP" connection-mark=EoIP disabled=yes
add action=accept chain=wifi-services comment="Winbox (8291/TCP)" connection-mark=winbox disabled=yes
add action=jump chain=wifi-services comment="drop all other wifi services" disabled=no jump-target=drop_wifi_services
add action=accept chain=public-services comment="SSH (22/TCP)" connection-mark=ssh disabled=yes
add action=accept chain=public-services comment="PPTP (1723/TCP)" connection-mark=pptp disabled=yes
add action=accept chain=public-services comment="Winbox (8291/TCP)" connection-mark=winbox disabled=yes
add action=accept chain=public-services comment="GRE for PPTP" connection-mark=gre disabled=yes
add action=jump chain=public-services comment="" disabled=no jump-target=drop_public_services
Re: Best Practioe for Limiting LAN Access from WLAN
That should be easy to combine. When you do your connection marking don't go by in-interface (if you are) but rather make an address-list that contains all internal network space. Drop that address-list coming in from the WAN in prerouting because you should never see it sourced from the Internet. That way all marking happens the same for all internal network. You can also do accepts and drops based on the access-list at that point, too.
Then combine your custom chains by putting the common stuff into one chain and jumping further into the common chain first, and then handling the special cases for each network.
Then combine your custom chains by putting the common stuff into one chain and jumping further into the common chain first, and then handling the special cases for each network.
Code: Select all
add chain=common-services action=accept connection-mark=ssh
add chain=common-services action=accept connection-mark=dns
add chain=common-services action=accept connection-mark=proxy
add chain=common-services action=accept connection-mark=ntp
add chain=common-services action=accept connection-mark=winbox
add chain=local-services action=jump jump-target=common-services
add action=accept chain=local-services comment="Allow vista icm udp to 3947 so the logs don't get filled" connection-mark=vista_icm disabled=no
add action=accept chain=local-services comment="accept mikrotik dude " connection-mark=dude disabled=no
add action=jump chain=local-services comment="drop all other local services" disabled=no jump-target=drop_local_services
add chain=wifi-services action=jump jump-target=common-services
add action=accept chain=wifi-services comment="Accept EoIP" connection-mark=EoIP disabled=yes
add action=jump chain=wifi-services comment="drop all other wifi services" disabled=no jump-target=drop_wifi_servicesRe: Best Practice for Limiting LAN Access from WLAN
Thank you. So a couple of quick follow-up questions:
1. Apart from being easier to read/manage is there also a performance improvement with having fewer rules and combining the common ones?
2. Is this the approach that's typically taken rather than bridging the interfaces and using firewall rules for the bridge? When would bridging the interfaces be used?
3. What else get's opened up by bridging? Is it strictly a level 2 vs. level 3 issue (e.g. ARP, Ethernet , PPP etc.)? Any ideas what this means in a home network environment?
Again, thank you so much for the quick responses.
1. Apart from being easier to read/manage is there also a performance improvement with having fewer rules and combining the common ones?
2. Is this the approach that's typically taken rather than bridging the interfaces and using firewall rules for the bridge? When would bridging the interfaces be used?
3. What else get's opened up by bridging? Is it strictly a level 2 vs. level 3 issue (e.g. ARP, Ethernet , PPP etc.)? Any ideas what this means in a home network environment?
Again, thank you so much for the quick responses.
Re: Best Practioe for Limiting LAN Access from WLAN
1. No, not really. What matters is how many rules get processed for a specific packet going through the chains, and how expensive the comparisons and actions are, not how many rules there are total.
2./3. Bridging puts everything on the same broadcast domain. You can still run bridge filters or even use the IP firewall filters on bridges. It really is a layer 2 vs layer 3 thing. Things that are different administrative domains should ideally be on different layer 3 networks - usually. Sometimes you want to bridge interfaces, such as bridging an AP radio to the ethernet segment the traffic should end up on. If your wireless network is just you it probably _should_ be bridged, but at that point you wouldn't be filtering traffic on the bridge because the wireless network is just an extension of the wired network, and all traffic should flow. If it's guest access and traffic should be filtered it is cleaner to also separate the two by a layer 3 hop.
2./3. Bridging puts everything on the same broadcast domain. You can still run bridge filters or even use the IP firewall filters on bridges. It really is a layer 2 vs layer 3 thing. Things that are different administrative domains should ideally be on different layer 3 networks - usually. Sometimes you want to bridge interfaces, such as bridging an AP radio to the ethernet segment the traffic should end up on. If your wireless network is just you it probably _should_ be bridged, but at that point you wouldn't be filtering traffic on the bridge because the wireless network is just an extension of the wired network, and all traffic should flow. If it's guest access and traffic should be filtered it is cleaner to also separate the two by a layer 3 hop.
Re: Best Practioe for Limiting LAN Access from WLAN
Thanks again. So one last quick one. Short of bridging and putting everything on one broadcast domain, is there an easy way getting bonjour/rendezvous/zeroconf to work across broadcast domains? I've seen some references in posts to EoIP tunnels but can't seem to figure out if and how that applies when there is only on router and the tunnel is between interfaces.
Re: Best Practioe for Limiting LAN Access from WLAN
In its current implementation Bonjour is just multicast traffic, so you shouldn't have to do much more than set up multicast routing on your router.
Re: Best Practioe for Limiting LAN Access from WLAN
It is multicast but I think it's intended only for the current broadcast domain and has a TTL of 1. I've tried mangling and increasing the TTL with no luck. Any other ideas or do I have to bridge the interfaces to get it to work?
Re: Best Practioe for Limiting LAN Access from WLAN
I don't think so. I think earlier version even refused to accept packets with a TTL lower than 255 to make it local net only, but recent versions work fine with packets that have had the TTL decreased. If TTL is the only stumbling stone you can use mangle in the prerouting chain to set arbitrary TTL values like you tried, I don't see why that wouldn't work.
On Macs you could use dns-sd to statically announce resources on each net pointing to the other one, or you could use DNS to statically map services. Both methods are described in articles you can find on Google, this one seems pretty good (PDF). I do think multicast routing would be the cleanest way to go but I have never set that up with either Bonjour or RouterOS so I can't be of much help.
Or you could, of course, just bridge the damn interfaces. Probably the easiest and fastest solution at this point.
On Macs you could use dns-sd to statically announce resources on each net pointing to the other one, or you could use DNS to statically map services. Both methods are described in articles you can find on Google, this one seems pretty good (PDF). I do think multicast routing would be the cleanest way to go but I have never set that up with either Bonjour or RouterOS so I can't be of much help.
Or you could, of course, just bridge the damn interfaces. Probably the easiest and fastest solution at this point.
Re: Best Practioe for Limiting LAN Access from WLAN
Thanks again for the advice. This has definitely been bugging me and I'd like to find a solution even though there are workarounds 
I used the packet sniffer and found that the mDNS multicast (224.0.0.251) goes into the router from the various interfaces but is never seen from again. TTL is definitely not 1 so you were right. Usually 255 or 254 depending on where it's coming from. The packets are not dropped or anything. They're just gone!
This is definitely not the case with the AP running DD-WRT. It passes along the multicast to RouterOS. hmmm... a bunch of threads about this all over the place but no real resolution without using some kind of proxy (e.g. Rendezvous Proxy). Unfortunately it's java.
I used the packet sniffer and found that the mDNS multicast (224.0.0.251) goes into the router from the various interfaces but is never seen from again. TTL is definitely not 1 so you were right. Usually 255 or 254 depending on where it's coming from. The packets are not dropped or anything. They're just gone!This is definitely not the case with the AP running DD-WRT. It passes along the multicast to RouterOS. hmmm... a bunch of threads about this all over the place but no real resolution without using some kind of proxy (e.g. Rendezvous Proxy). Unfortunately it's java.