On 6/13/22 12:22 PM, Jon Lewis wrote:
On Mon, 13 Jun 2022, Brie wrote:
Who knows... Hard to know if I'm taking a different network path or just going through the same routers but bypassing whatever is blocking the packets.
You might be able to infer that from the hops that show up in traceroutes.
So, I was looking at that, and the lack of rdns on many IPv6 hops is... aggravating. CL/Lumen does embed ipv4 addresses in some of their IPv6 router addresses, but not all. So, not really enough to determine really if I am, unfortunately.
I went so far as to even randomize source/dest ports on each end in case it was some sort of misguided filtering (ie: port 12345 -> 54321 instead of 12345 -> 12345).
That really makes it odd. If you tried changing the src/dst ports with v4, and your VPN traffic still would not pass, but iperf would, what kind of filtering/breakage could CL or Comcast have that would just stop your VPN traffic regardless of ports?
I wonder if this is a misguided/misbhaving filter rule, or something actually broken eating your packets. Having dealt with something far stranger many years ago, I totally get the aspects of "big telco can't help / won't let you even talk to someone who can understand your explanation of the issue" and "I don't care how I solve this, as long as I can make the issue go away."
One thing I did not think about before reading your response, was the size of the UDP packets. Its possible something's blocking UDP packets below a certain size. iPerf is going to send packets of a consistent size for testing, whereas WG is likely to have varying sizes depending on contents of packets. Maybe I need to do some testing with varying packet sizes.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org