Filtering intra-VLAN traffic?

So, I work for a computer shop and were have been having issues with our VoIP system getting spammed/hacked/explored or otherwise tampered with at one of our locations. As this isn't the location that I am usually at, I haven't been able to observe the network traffic when it has happened.

After getting a $5,000 network security quote from a local IT company I was able to convince my boss to instead pick up a $250 WRT3200ACM router so that I could install OpenWRT on it instead -- we're a small business, so the enterprise-class equipment they were recommending really is overkill for our needs.

After spending the last few days after-hours at the shop setting things up, I noticed a couple things about the VoIP system: On the old router, there were no UPnP mappings and no port forwards set. To me, this means that due to the PNAT setup, there really is no way for an attacker to compromise the phone system from the outside -- the box simply isn't accessible. Clearly, this means that the attack is coming from inside the network. I mean, I could simply re-install Windows on all the work machines, but I'm more interested in defeating this at the networking level since if the computers were to get compromised again it wouldn't take down that shop due to constant and incessant spam calls.

So, with our new WRT3200ACM I set up a couple of things that are helpful in our line of business: The router has 3 VLANs and 3 firewall zones: WAN, LAN, and Customer (for potentially compromised customer devices). I have 3 of the four ethernet ports on the router assigned to VLAN 1 (lan) and one port to VLAN 3 (customer). I also set up two wireless networks, one for store use, one with WLAN isolation for customer devices.

Just for the sake of clarity, I have the following logical setup:

  • br-lan composed of eth0.1, and 3 separate radio interfaces (the non-guest WLAN), this is tied to the 'lan' firewall zone, as per usual.
  • br-customer composed of eth0.3 and 3 other radio interfaces (the guest WLAN interfaces), tied to a 'customer' firewall zone.
  • Inter-zone forwarding is denied by all zones except guest->wan and lan->wan

Just to be safe (and this is probably overkill), I also added firewall rules to tag legitimate connections between the WAN and the phone device (i.e., originating from or destined for the networks of our IP phone provider) and to deny all untagged packets/connections to the IP phone box. So far, so good.

But, this is where I hit a snag: a device connected via Ethernet to the router on a port on the same VLAN can still, for example, access the web interface of the IP phone box even though it's not a firewall "authorized" connection. I've done all kinds of firewall logging and can never seem to capture packets going from the "unauthorized" lan device to the IP phone box. After mulling it over, I think I know why this is: it's the internal switch doing its job: relaying the packet directly to the destination and thereby bypassing any routing the firewall might do -- from a layer 3 perspective, no routing needs to be done so FORWARD, PREROUTING, POSTROUTING tables are never hit and from a layer 2 perspective, the devices are adjacent so the ethernet frame can be relayed via layer 2 without ever having to consult layer 3, bypassing iptables.

So, the situation is this: I need to block all intra-LAN communication with this box (it does not need to talk to any other device than our IP phone provider) while allowing it to still continue talking via the WAN. This must have to be done at layer 2, since the packet never really has to be routed.

I've checked out a couple of iptables kernel modules such as ebtables and I think this might be the solution to my problem, I just can't figure out exactly where/how to use it. If my understanding it correct (and it should be), any IP packet that cannot be mapped via ARP in the ethernet frame, sets its destination MAC to that of the default gateway and traffic from the WAN should always have the ethernet source MAC set at the default router. This means that I should, theoretically, be able to DROP or REJECT all ethernet packets destined to the known MAC of the IP phone box if the packet's source MAC is not that of the default gateway.

Is this the correct way to go about this?

(Sorry, I really didn't mean to post the question before trying it on my own LAN but here it is -- can't delete it)

whats your old hardware ? if upnp is not their STUN or something other technology have to be their else frequent disconnections and long delays will occurs. i worked with voip on my college project

The improper configuration of NAT ( full cone nat ) leave a backdoor to enter into the network

for the new setup you are taking plz send you config files i am really not understanding your case , you will get a nice solution here in this community

If config files are not available please reframe the question explaining the topology ( vlans )

I would post the configs, unfortunately, I don't have access to the router at this point in time. However, I've got pretty much the same setup on my home router and I'm tinkering with it in the same fashion, trying to keep LAN connections from going to my Raspberry Pi while still allowing it to access the internet -- it's a little simpler since I don't have to worry about the tagging firewall rules as such.

Also, since Wifi->Switch communication is effectively blocked via Wifi isolation, I don't have to worry about it in that context. It's only Ethernet->Ethernet communication behind the same switch that I'm having trouble filtering since the switch itself routes the packet directly to the destination ethernet port rather than having to go through layer 3 routing/decision making.

/etc/config/network (relevant parts):

config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option igmp_snooping '1'
	option dns '1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001'
	option ifname 'eth0.1'
	option macaddr '62:38:e0:xx:xx:x1'

config interface 'wan'
	option proto 'dhcp'
	option ifname 'eth1.2'

config interface 'guest'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.2.1'
	option dns '1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001'
	option ifname 'eth0.3'
	option macaddr '62:38:e0:cd:52:e3'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

#lan VLAN
config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '2 3 5t'

#wan VLAN
config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'
	option ports '4 6t'

#guest VLAN
config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '0 1 5t'

I think that's really the only thing that's relevant with my current home setup. I'm trying to DROP layer 2 traffic (since its traffic to the same subnet and behind the same switch -- the router's built-in switch) to my Raspberry Pi (I'll call its MAC address PIMAC) for everywhere BUT the wan. So, of course, this can't be accomplished with iptables. I've installed ebtables hoping to filter the traffic, but for some reason I still can't get it to work. I looked at the documentation (specifically, under Figure 2b) and it mentions that in situations where the two devices are on the same side of the bridge the traffic will be ignored, but it will still pass through the BROUTING chain of the broute table, which is the only place that I can potentially filter the traffic.

So, I applied this rule for simple testing, hoping that it would drop all traffic to my Pi, but it's non-functional for some reason:

ebtables -t broute -A BROUTING -d PIMAC -j DROP

On a side note, it kind of sucks that ebtables doesn't have a LOG target, so I can't see if anything's even being triggered.

ohk i understood this last post of yours very well , but top opening post is still not clear so unable to map things

it will be very helpful if you tell the situation in accordance with this config file that is your home setup (orgetting the first exaplaination of the situation)and paste you firewall and wirelss file too plz

/etc/config/firewall

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 target 'ACCEPT'
	option proto 'udp'
	option dest_port '67-68'
	option name 'Allow-Guest-DHCP'
	option src 'guest'

config rule
	option target 'ACCEPT'
	option proto 'tcp udp'
	option dest_port '53'
	option name 'Allow-Guest-DNS'
	option src 'guest'

config rule
	option src 'guest'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
	option name 'Allow-guest-DHCPv6'

config rule
	option target 'ACCEPT'
	option src 'guest'
	option name 'Allow-mDNS-guest'
	option proto 'udp'
	option dest_port '5353'

config defaults
	option syn_flood '1'
	option output 'ACCEPT'
	option forward 'REJECT'
	option input 'REJECT'

config zone
	option name 'lan'
	option output 'ACCEPT'
	option network 'lan'
	option forward 'REJECT'
	option input 'ACCEPT'

config zone
	option name 'wan'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6'
	option input 'DROP'

config forwarding
	option src 'lan'
	option dest 'wan'

config include
	option path '/etc/firewall.user'

config zone
	option name 'guest'
	option output 'ACCEPT'
	option network 'guest'
	option forward 'REJECT'
	option input 'ACCEPT'

config forwarding
	option dest 'wan'
	option src 'guest'

config forwarding
	option dest 'guest'
	option src 'lan'

config include 'miniupnpd'
	option type 'script'
	option path '/usr/share/miniupnpd/firewall.include'
	option family 'any'
	option reload '1'

Nothing special here, but again I'm looking at Layer 2 traffic so it's not applicable

There's also nothing relevant in /etc/firewall.user to this situation

The issue is that the hardware switch is routing the ethernet frames directly to my Raspberry Pi without passing through IP tables (since my laptop is connected to the same switch and VLAN), which is why I'm trying to use ebtables instead (Layer 2).

I did figure out logging on ebtables (had to opkg install kmod-ebtables-watchers) but even logging every packet, I'm not seeing the pings I'm sending to my Raspberry Pi from my laptop. So, I guess I was barking up the wrong tree with ebtables. How else can I intercept the frames inside the switch before they get to the other port?

Perhaps since the physical switch in the router is only exposed as one interface (eth0) in the kernel itself, it's not possible. It's possible that they router is only seeing the flooded frames and outbound frames from the physical switch rather than all of the traffic within the switch.

ohk , I think if we see it like this

if we want to disable all ethernet LAN devices to block reaching the default gateway ? what will you do ?

ebtables ? or ip tables ?

192.168.2.X block to reach 192.168.2.1

i haven't practically done this lan to lan blocking , but this is the first thought that came so trying to get a direction

But that's the thing. I want to keep those LAN devices from reaching a single other LAN device -- in this example my Raspberry Pi -- which is attached to the same side of the switch. Since they're on the same side of the switch though, the switch is using its internal lookup table to simply pass the traffic from, say, port 3 to port 4 since both devices are directly connected to it.

I'm hoping to find a way to intercept the traffic after it gets into ethernet port 3, or before it goes out port 4.

I'll put it this way: Even if I set an iptables rule to deny all traffic to 192.168.2.2 (my Raspberry Pi), my laptop is still able to ping it. And that's the issue I'm up against. If I can't stop all of the traffic, then my IP phone at my workplace is still potentially vulnerable to an infected ethernet-connected machine on the same VLAN at the workplace.

@lleachii your call

i am still standing on what i theoritically said , will try out practically in night

Even ebtables does not see the laptop->Pi ping happening when I log every single packet. So, it seems that

  1. The switch is working perfectly fine from a hardware perspective
  2. I'm going to have to find a way to stupefy the switch hardware so that it doesn't actually do any switching

Instead, maybe I can somehow send all switch traffic all traffic into eth0 and let the kernel/my firewall rules decide whether to send the traffic back through the switch or not -- but even that would be tricky since I can't access individual switch ports and I surely don't want to turn the switch into a hub -- that would defeat the purpose.

So, here's what I did:

  1. My Raspberry Pi is 192.168.2.2 (connected to switch port 4 -- VLAN 3/guest)
  2. My laptop is 192.168.2.3 (connected to switch port 3 -- VLAN 3/guest)
  3. I started a ping from my laptop to the Raspberry Pi
  4. I added this rule to iptables: iptables -t mangle -A PREROUTING -d 192.168.2.2 -j DROP
  5. Checked my ping, it's still going and 100% success rate
  6. Removed the old rule and added this one: `iptables -t mangle -A PREROUTING -d 192.168.2.2 -j LOG --log-prefix="To Raspberry Pi "
  7. Observed no relevant log outputs (at least, not from my laptop)

So, the traffic is never leaving the actual switch hardware since the switch is doing its job and handing the traffic directly from port 3 to port 4 (and vice versa).

I guess in the end, the only thing I can really do to keep this from happening is to subnet out the IP phone on a lonely /29 subnet, which will force all communications to be routed (i.e., destined for the router's MAC address), bypassing the switching issue, elevating Layer 3, and filtering it from there.

You might find it useful to read guest-wifi-firewall-rules-and-security-questions; I had a question very similar to yours. The way that I solved it was to put the device I wanted to filter on a separate VLAN; that made it easy to filter. For example, I use these rules for VLAN3:

FORWARDING RULES
VLAN3 is for IP cameras, or anything else that should be strictly contained to just its own VLAN
Block VLAN3 from accessing the Internet or anything inside the house
iptables -I forwarding_VLAN3_rule -s 0.0.0.0/0 -j DROP

**** INPUT RULES ****
Block VLAN3 from accessing anything inside the router
iptables -I input_VLAN3_rule -s 0.0.0.0/0 -d 0.0.0.0/0 -j DROP
Allow VLAN3 to access the DHCP server
iptables -I input_VLAN3_rule -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp --sport 68 --dport 67 -j ACCEPT

You may need to allow your VoIP hardware to also access the DNS, in which case you would also need:
iptables -I input_VLAN4_rule -s 0.0.0.0/0 -d 0.0.0.0/0 -p tcp --dport 53 -j ACCEPT
iptables -I input_VLAN4_rule -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp --dport 53 -j ACCEPT

If you use device names from your static leases in your firewall rules then you also need to read custom-firewall-rules-may-not-work-after-reboot

Unless you know I've directly worked on something previously...please refrain from paging me to topics I have not participated in.

...I would have told the OP that intra-interface traffic never touches the router, so I'm lost on what's trying to be accomplished here with the OpenWrt firewall.

I'm not sure what you're telling the OP to do, then...nor why you made him pull all these configs.

What you want is very simply to put the VOIP devices on their own VLAN and then allow only a restricted set of LAN devices to forward to the VOIP vlan for management of the devices.

1 Like

why you got so much irritated dude ? if you are not intrested in this you could have tell as a reply too

now clear i wont involve you. and expect the same from you

when i said to the community that i will disclose the concept . you were the one to point out me.
so from now you listen. I am also declaring as you did never ask or instruct me what to do and when to do

:confused:

I don't understand the source of your agitation. I had to read this, at a time I dedicated not to, as you said you would never leave me in a position to say you didn't follow-through. I'll leave everyone else to find that post (if interested).

Next, this response has nothing to do with the OP. You could get flagged...


This obviously has nothing to do with the OP's topic, so I won't bore readers with responding to this here - thus confusing them further.

You know there is a Private Message feature if you have a private redress with me, correct?

So, I was messing around with this setup using my RaspberryPi at home and I was able to accomplish my goal simply by adding it to another VLAN. The VLAN interface is attached to the same bridge as the other devices and the same firewall zone. This worked perfectly at home.

However, I tried to replicate the setup with the same configuration at work by assigning the phone its own VLAN, and attaching the VLAN interface to br-lan -- keeping the same firewall zones attached. However, for some reason in this case, it didn't work as expected and I was still able to ping the phone device. I'm really not sure why it didn't work, but it may be due to my firewall rules on my home device.

I ended up creating a new interface with an address of 192.168.1.249/30 at the end of my customer devices subnet (192.168.1.128/25), adjusted my customer devices DHCP range accordingly, created a new firewall zone that only allows forwarding to the wan and attached it to the new interface.

So far, so good. This forces the traffic into Layer 3 allowing me to filter it accordingly (actually, it's not really necessary to filter it at this point, since the firewall zone forwarding rules take care of that).

As a side note, is there anyway to define a gap in a DHCP range in OpenWRT? When I was setting up my configuration on the work computer I realized that the 192.168.1.129/25 DHCP server was assigning leases rather than the more specific DHCP server on interface 192.168.1.249/30. So, I had to back off my DHCP range of the 192.168.1.129/25 interface to allow a gap at the end that wasn't covered by the DHCP pool and would allow me to run another DHCP server there.

Honestly, it won't ease future configuration necessarily in this case, but what if I wanted to move the subnet to the middle of the DHCP range rather than the very end. Would I have to define two pools for one interface, or is there a way to exclude specific addresses from an already defined pool?

Because you keep placing them in the same firewall zone.

Although, a zone forward REJECT or DROP rule should have worked in this case.