Weird activity on wan interface

zardoz1

Hello, I recently moved and transferred my internet connection to a new place using a custom built pfsense box with a draytek vigor 130 in bridge mode, Anyway since I started using pfsense at new place I’m getting some weird firewall blocks that doesnt originate from or have a destination in my network with ips starting with 10.0.0.0 destination port is 138 and it shows interface as igb0 (its my wan port and the usual logs show the interface as wan not igb0) what could theese be? Should I be worried? Thanks in advance and heres a screenshot:
screenshot

johnpoz

@zardoz1 that is broadcast traffic.. Are you on a pppoe connection? Does your new ISP use vlans for your wan?

Traffic showing hitting just the raw interface vs wan or lan or whatever you named it normally means the traffic is hitting the interface, but not actually what your "wan" is..

Could you post your interface assignments?

zardoz1

@johnpoz Yes it’s a pppoe connection and i set the vlan tag (35) on the draytek modem needed for isp my interface assignements are:
igb0 = WAN
igb1 = LAN (to switch)
igb2 = WIFI (plugged to an AP)
igb3 = unassigned

I’m also getting things blocked as usual on my WAN interface but it shows the interface name as WAN on logs, only this netbios traffic is logged as igb0

johnpoz

@zardoz1 yeah the stuff that is hitting your igb0 doesn't have the tag.. Its noise on your isp connection.. Unless that 10 network is between you and your "modem" and there are other devices on that network?

But that ending with .255 is normally a directed broadcast if you were say on a /24.. Unless you had like a mask that allowed that to be a host address like /19

With looking at the source traffic - yeah you would have to be running like a /19 for it not to be broadcast? What is the mask on your igb0 interface and its IP.. I would guess /20 which would make that 10.134.111.255 the broadcast of 10.134.96.0/20 network You can view that with ifconfig from cmd line on pfsense.

You could create a rule not to log it if you wanted to.. But there is nothing you could do about really if from your isp network. You don't show but take it that is UDP, to 138 those are host or workgroup announcement from other devices on your isp network..

Do a packet capture under diagnostics for that port 138.. And then open with wireshark for example and you can see what they are announcing..

BTW - more wanted the screenshot of your assignment screen, so could see if you had vlan assignment.. But if you know your using vlan - then yeah makes sense why your seeing on interface vs "wan"

edit: I personally would contact your isp and tell them to clean up their network - that shit shouldn't be broadcasting between their clients connections.. Simple enough to filter that out.. Once you get a pcap - send it to them showing the noise your seeing.. There is zero reason for customer A to see such broadcast from customer B connection, etc.

zardoz1

@johnpoz I also think this might be isp noise too, was using same Isp at old place and that line was constantly getting hitt by facebook and google servers all the time while no device on network was running and I was thinking other people’s connections are being routed to me by mistake or something don’t know, I’m nowhere near knowing what I’m doing about this stuff mostly but this private network on supposed wan interface got me startled,
Anyway yes that hits are udp here a screenshot of it with normal Wan hits mixed in:
firewall view

Screenshot of my assignments screen, I didn’t assign VLAN on the pfsense but have it assigned on the modem (am i doing something wrong here?)
assignments

There are no devices between pfsense and the modem its like isp line goes in to modem then modem goes in to pfsense. Also isp assigns me a private Ip but not in the range of that broadcast it’s 100.94.182.92 right now and always starts with 100 and heres the output from ifconfig:

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e120bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:8a:e4:90
	inet6 fe80::a236:9fff:fe8a:e490%igb0 prefixlen 64 scopeid 0x1
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: LAN
	options=e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:8a:e4:91
	inet6 fe80::a236:9fff:fe8a:e491%igb1 prefixlen 64 scopeid 0x2
	inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: WIFI
	options=e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:8a:e4:92
	inet6 fe80::a236:9fff:fe8a:e492%igb2 prefixlen 64 scopeid 0x3
	inet 192.168.155.1 netmask 0xffffff00 broadcast 192.168.155.255
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:8a:e4:93
	media: Ethernet autoselect
	status: no carrier
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0<> metric 0 mtu 1536
	groups: enc
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=100<PROMISC> metric 0 mtu 33160
	groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
	groups: pfsync
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
	description: WAN
	inet 100.94.182.92 --> 100.94.128.1 netmask 0xffffffff
	inet6 fe80::a236:9fff:fe8a:e490%pppoe0 prefixlen 64 scopeid 0x9
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

I did packet capture on WAN (there is no option to do it on igb0) but nothing is captured maybe because they aren’t hitting WAN as in firewall logs?

stephenw10

Yeah, I agree, your ISP has something misconfigured there.

This is not traffic hitting your WAN IP in the PPPoE connection which is to be expected.

This is traffic outside the PPPoE coming across the DSL link, probably being untagged by he modem and hitting the parent interface. That should not happen.

In the gui you can only pcap on assigned interfaces. You can assign and enable igb0 as a new interface and just set no IP on it. Then you can capture on that. That's also what you would do to access the V130 gui from behind pfSense.
Or you can pcap on igb0 directly at the CLI without assigning it:
https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/tcpdump.html

Steve

johnpoz

@stephenw10 do you think its also odd that he is seeing the hits in the firewall, when from what he posted igb0 has no IP on it at all.. So why would the traffic be sent up the stack? For the firewall to even see it?

I would of assumed that igb0 had an IP on it in the 10.x range he was seeing the hit. I could see seeing that traffic via a sniff. But unless the nic has an IP that matches the traffic in some way, be it broadcast or unicast it shouldn't even pass it up the stack for firewall to see?

stephenw10

The default block rule applies to all interfaces so you can see it there. Like you can see passed and blocked traffic to localhost sometimes. As long as it is UP which it must be here for PPPoE (via netgraph) to use it.

zardoz1

@stephenw10 assigning the interface without ip worked for pcap, here's the file if you guys are interested in seeing it;
https://we.tl/t-eQoPbFPgHX

pcap

I’ll try to reach isp too but whenever its something about other than a service interruption call center don’t care. Probably just gonna have to live with it.

johnpoz

@zardoz1 see those are announcements

Noise you shouldn't be seeing to be honest..

You can for sure change your rules so you don't see that noise.. Create a rule that doesn't log it, or turn off logging of default rule and then create rules of the stuff you want to see only.

This is what I do - I only log tcp syn traffic, and then common interesting udp ports.

stephenw10

Yeah, I would also block it without logging. It shouldn't be there IMO but the volume is not high enough to be anything but a nuisance.