Broadcast storm WAN interface responding to LAN NBNS broadcast traffic (UDP 137)

wpatterson82

Hi guys,

While troubleshooting random false CARP failovers with our pfSense firewalls, I noticed that one of our two WAN interfaces is trying to respond to local broadcast traffic. In turn, this is creating a broadcast storm on that ISP connections VLAN and consuming all bandwidth.

As you can see from the screenshots I have attached, running tcpdump on the LAN interface shows the NBNS broadcasts. Running the dump on the WAN interface shows the public IP address of that interface trying to respond to the private network.

When only one firewall is up and running it's not a big deal because the traffic is so small, however when I bring up the second firewall it creates the broadcast storm. Essentially my redundant firewall system is broken and I am sad :(.

Any help would be appreciated, we are running on pfSense version 2.1.5-RELEASE (amd64) on both machines.

Please see the attached screen shots and rule configuration.

pfsense_lan.PNG_thumb

pfsense_wan.PNG_thumb

wpatterson82

Just some more information to help - I am not bridging any interfaces, and the LAN and WAN interfaces live on completely different switches. There really isn't any other way of the broadcast traffic to get to the WAN interfaces except through the firewalls.

Both firewalls are identical in hardware and pfsense versions.

There are three total WAN interfaces (two are running through one port via a VLAN trunk), and 6 LAN interfaces.

johnpoz

And why would broadcast traffic be forwarded? Why would pfsense try and answer - it wouldn't.. And let say it was, why would it send it out that interface?

Do you have mask setup wrong on pfsense where 172.20.1.255 is a host address.. say for example 172.20.0/22 where client is on /24 ?

Why don't you open those captures up in wireshark.. Post them so we can see if forward or answer.. You don't have timestamps in the 2nd picture..

Makes no sense that pfsense would send traffic out wan for network it has local - even if was seen as host address.. Lets see your firewall rules and interface IPs, routes, etc.

There is no reason pfsense would do such a thing. Do you have any packages installed?

wpatterson82

Wow. That's the most aggressive post I've seen in awhile. If I knew why pfsense was forwarding this traffic I wouldn't have posted this topic.

I also opened a support ticket and the pfsense techs have confirmed this is actually a problem. All of my subnet masks are properly set.

As a temporary fix they had me set a rule LAN –> LAN with no gateway. That is working for the moment.

I'll update this thread when they figure out why this is happening.

johnpoz

Aggressive? So asking questions is aggressive to you?? How and the F do you get anything done if you take offense if people ask you for details and post their own thought process while reading the post?

You stated there was a rules attachment
"and rule configuration."

I don't and didn't see that..

I have to assume that pfsense was given your config, access to pfsense to validate - which I do not have the luxury of seeing while attempting to help you and open a dialog.

But if you think that was aggressive ;) I sure hope dok doesn't run across this thread ;) hehehe

cmb

Being forwarded by route-to (firewall rule specifying a gateway) I'm guessing, add a block rule on whichever interface is em4 for destination 172.20.1.255, at the top of the list.

wpatterson82

johnpoz - Please troll elsewhere.

cmb - Thanks for your suggestion, the solution was actually to add an ALLOW rule at the top of my LAN interface which is just LAN -> LAN with no gateway. For some reason pfsense was allowing the broadcasts to pass through and that seemed to have stopped it. The techs at pfsense are looking into the reason why but nothing obvious is jumping out. I'll update this thread once they find out why.

snvdberg

Did this ever get fixed besides the work around?

sprinteroz

The attack is called bad tunnel I Have been in contact with VPN company's as all there windows servers (all versions of windows from W95 to W10) are getting a attack throw ports 135, 136, 137, 138, 139, 455, 500 but mainly port 137 dew to them running windows under windows 10 anniversary update.

BadTunnel exploits a series of security weaknesses, including how Windows resolves network names and accepts responses; how IE and Edge browsers support webpages with embedded content; how Windows handles network paths via an IP address; how NetBIOS Name Service NB and NBSTAT queries handle transactions; and how Windows handles queries on the same UDP port (137) – all of which when lumped together make the network vulnerable to a BadTunnel attack.

Here’s an attack scenario, as explained in Yu’s technical paper:

1. Alice and Bob can be located anywhere on their network, and have firewall and NAT devices in-between, as long as Bob’s 137/UDP port is reachable by Alice.

2. Bob closes 139 and 445 port, but listens on 137/UDP port.

3. Alice is convinced to access a file URI or UNC path that points to Bob, and another hostname based URI such as “http://WPAD/x.jpg” or “http://FileServer/x.jpg”. Alice will send a NBNS NBSTAT query to Bob, and also send a NBNS NB query to the LAN broadcast address.

4. If Bob blocks access to 139 and 445 port using a firewall, Alice will send a NBNS NBSTAT query after approximately 22 seconds. If Bob instead closed 139 and 445 port by disabling Server Windows service or NetBIOS over TCP/IP protocol, Alice do not need to wait for connection to time out before send the query.
info taken from this page: https://goo.gl/OZnC9b

Here is a google search if you want to read up on it more: https://goo.gl/ZTNH26