[solved] strange ISP behavior - normal?

[OPNenthu]

My parents recently got Verizon service at their home and I have remote access.  I logged in today to upgrade their OPNsense and saw something unusual in the firewall logs which is still on-going.  Screens attached.

I've never seen this pattern before (I don't have Verizon myself) so am not sure if this is typical for the ISP, or is this part of an attack attempt?  I have no idea what service corresponds to port 35313/udp or what they might be trying to do here.  The reason I'm assuming it's Verizon is because the IPv6 prefix (2600:4040:7e...) belongs to them.

Mixed in with these are a bunch of foreign IPv4 addresses trying to reach 8080, 443, 22, etc., but I see this kind of activity all the time.  One of them is a FireHOL-listed source so those could be unrelated to whatever the Verizon IPs are doing.  Or maybe coordinated, I don't know.

The interface IP they are trying to access (:fe4c:19b) is non-existent AFAIK.  I don't find any reference to it in the firewall, nor is it listed in the NDP table under Interfaces->Diagnostics.  I also cannot ping it.  The local UniFi controller does incidentally have :fe4c: in its address, but the remaining bits are different.

The firewall is doing its job so the only reason I'm concerned is mostly out of abundance of caution for my parents.  This doesn't look typical to me.  I've advised them to return the ISP-provided gateway so they wouldn't be charged monthly for it, though I hope I'm providing adequate replacement security with just a plain OPNsense install.  There are no services exposed on the internet except for a WG port for the s2s tunnel, so I felt no need for anything more (IDS/IDP, Crowdsec, etc.)

[OPNenthu]

Could this be another Verizon subscriber being naughty?

The source interface IDs are changing but the prefixes are between 2600:4040:7e71 and 2600:4040:7e70.  Every once in a while an icmpv6 request gets through from 2600:4040:7e70::1, which seems wild to me.  Have they got at least a /44 delegation that they're abusing?

I wonder if the fact that icmpv6 echo is allowed by default might be inviting attention?

[meyergru]

Most surely not, because the IPv6 address range is too vast to explore.

This might be one of two things:

1. A site-2-site VPN setup by someone that tries to access a node via dynamic DNS and you have inherited that (IDK if Verizon has dynamic or static IPv6 prefixes).

2. A shared IPv6 broadcast domain where your "Verizon neighbors" can actually see IPv6 broadcast traffic and see your IPs). IDK if Verizon separates such traffic as they should.

BTW: "Someone" includes you - think of tailscale. The target IP must be found somehow, via DNS, broadcast traffic or registration by inside-out-traffic from one of your clients.

[OPNenthu]

1. A site-2-site VPN setup by someone that tries to access a node via dynamic DNS and you have inherited that

It probably is something in my WG setup but I don't understand what you mean here r/e inheriting.  Both sides are dynamic and I'm using two DuckDNS domains for site A and site B, but the source IPs in the F/W logs do not match any of the assigned IPs according to the DuckDNS status page (also checked the WAN interface assignments in OPNsense).  Those prefixes are not "mine" as far as I can tell.

I used ULA VIPs internally for the v6 tunnels, so as to avoid the whole issue of dynamic GUAs and interface identifiers for the F/W rules.

2. A shared IPv6 broadcast domain where your "Verizon neighbors" can actually see IPv6 broadcast traffic and see your IPs

Point #2 is also interesting, and concerning.

I don't know how Verizon filters its network but I did use the existing coaxial wiring in my parents' house to add a couple APs and a downstream switch in the family room.  In the past they have had both Satellite and Cable services using these coax runs (not at the same time), but currently neither service is active so the wiring was available.

I made sure to disconnect the unused input from the old satellite dish (to avoid accidental egress) and converted the 'Office' leg into the input for the MoCA splitter. The office is where OPNsense lives and what ultimately connects to the Verizon ONT over Ethernet.

Did I create a potential issue?

[meyergru]

1. I mean you inherited their address and the other node still accesses that via the DynDNS entry. Imagine somebody else has set up a complex site-2-site setup where some of his friends or colleagues once contacted him. Some friend or neighbor or he himself has moved or there is a problem with his DynDNS and now it still points to his old IP, which now is your prefix that you inherited.


2. IDK that technology, but potentially, what you are seeing on OpnSense WAN side are the ones coming over your MoCa splitters and adapters.

[OPNenthu]

Imagine somebody else has set up a complex site-2-site setup where some of his friends or colleagues once contacted him. Some friend or neighbor or he himself has moved or there is a problem with his DynDNS and now it still points to his old IP, which now is your prefix that you inherited.

Now I got it :)

I will try rebooting their router tomorrow.  From what I have seen so far, Verizon changes the prefix often and on each reboot.  For that reason I configured one of the peers with a keepalive interval in WG (the recommended 25s).

[OPNenthu]

Thanks @meyergru, that was the issue.  The gateway picked up a new prefix now and those WAN requests have stopped.