How to block unknown IPv6 across tunnel
-
I'm detecting alerts for remote-to-remote traffic across my IPv6 tunnel interface, but I'm unsure how to block using pfSense. Can you tell me how to drop traffic from these IP on the tunnel interface? I don't have any of those IPv6 addresses...
Remote Client and Remote Server [Flow: 2607:fc20:4020:2bde:0:2c... Remote:34960 2a03:2880:f22c:1ce:face:... Remote:3478] [UDP] [Application: Unknown] -
That depends a lot on the relationship of those addresses to the desired ones. Perhaps you could create a rule that allows only the desired addresses, followed by one that blocks everything else.
-
That's the strange part of this whole thing... I have default deny on all interfaces (at least I think I do), so shouldn't pfSense block anything not matching a rule?
I think matching specific IPv6 addresses to block is like holding back the ocean....
-
@msf2000 If it is of any use, this appears to be traffic from T-Mobile to Facebook, most likely some form of STUN or TURN protocol.
I can only think that there is a misconfiguration at the ISP/Tunnel provider that you would cause you to receive traffic not specifically for you. -
Where exactly are you seeing that flow?
That one IP is owned by facebook
2a03:2880::/29
Just because you see a flow, doesn't mean it went anywhere, firewall could of blocked it.. Your just seeing one side of the traffic, sent from IP1 to IP2..
Not sure why that should be listed as unknown 3478 is common STUN port..
-
OK, that actually helps. My sensor (IDS) is located inside the firewall, so I would see connection attempts even if blocked by pfSense.
My working theory is that a mobile device is switching from LTE to Wifi but keeping their old IPv6 address....
I will try blocking unauthorized IPv6 on the inside and see if I get a hit (log).
-
@msf2000 I believe your theory is correct. I have seen this type of behavior before on my WLAN infrastructure whereby the device sends traffic from the LTE IP address but on the WiFi interface. I don't know if this is a mobile OS problem or an application problem.
In general, it is wise to ensure that all traffic entering the Internet from your devices can only emanate from IPs that are assigned to you. This is known as network ingress filtering, BCP38 aka RFC2827, and a good practice.
Since pfSense generally only applies rules on inbound traffic, you would have to create a floating rule on the outbound WNA traffic, dropping anything NOT from your source subnet(s).–A.
-
@msf2000 said in How to block unknown IPv6 across tunnel:
My working theory is that a mobile device is switching from LTE to Wifi but keeping their old IPv6 address....
That would explain the traffic for sure. Normal rules should be limited to the X net anyway, default rule would block it if not allowed via a source NET rule..
If your not logging your default, or you have your allows open to more than what the source net would be on that interface.. Yeah you can turn on default logging, make sure your only allowing source.. Or sure create a specific blocking rule that logs..
-
@msf2000 said in How to block unknown IPv6 across tunnel:
I think matching specific IPv6 addresses to block is like holding back the ocean....
Here are my guest WiFi rules. They are very effective for both IPv4 and IPv6.
-
@awebster said in How to block unknown IPv6 across tunnel:
I have seen this type of behavior before on my WLAN infrastructure whereby the device sends traffic from the LTE IP address but on the WiFi interface. I don't know if this is a mobile OS problem or an application problem.
Actually, this is entirely possible with Linux and Android is based on Linux. For example, I can specify the source interface and it's address will be used for the source. Another example, with my notebook computer, connected via WiFi, I can ping the WiFi address, even though it's connected via Ethernet. Other than desktop computers, just about everything is based on Linux, BSD or other *nix and I would expect them to behave the same way.
-
I'm cleaning up the rules now. I thought I would mention that I found this bug too:
https://redmine.pfsense.org/issues/11572Basically, my IPv6 block lists we not working because the rule was set for IPv4 with IPv6 lists. :( Easy fix, but a sneaky bug for sure.
