On Fri, Apr 18, 2025 at 03:17:24PM -0400, Mike wrote: > Is your ISP blocking traffic or are you just doing this to see if you can? > I just can't think of a use case for what you're trying to do and wondering > if there could be a different way to achieve what you're trying to do.
There is another way that this might work, I think, and it may even be the correct way. But here's the full story. I have two OpenBSD hosts NATted behind a regular home broadband router. Both of them are using l2tp to tunnel their way to a static IP out on the open Internet. (That means the port in question is 1701, not 1337, and like the subject says, all traffic is UDP.) The easiest OpenBSD way to do l2tp is to use xl2tpd from ports. As written, you can specify a port to use to xl2tpd, but that is the port it will use for both sending out packets and listening for replies/incoming new stuff. I am hoping that my tunneling service provider's l2tp implementation sends packets back to the l2tp client's source port: so, if it receives on port 1701 a packet coming from a client that's sending from port 17010, I hope it will send packets to the client on 17010. But I don't know if that's how it works on their side. Still, let's assume it does. Why do I care? (Disclaimer: I may not fully understand what I'm talking about!) Well, remember that my OpenBSD hosts are behind a NAT. They're both sending l2tp packets --- out of their own ports 1701 --- to port 1701 on the same host out on the public internet. The remote host is sending packets back to the same consumer broadband IP on port 1701, or so I assume. There's nothing to help it NAT, in other words. All the traffic from both machines behind the NAT looks the same. Practically, what winds up happening is that just one of my hosts can use l2tp; the other fails to connect, probably because the tunneling service doesn't understand what all the "extra" packets from the same consumer broadband IP are all about. The pf trick I'm looking for allows me to try changing xl2tpd's UDP source port on one of my machines without modifying xl2tpd. If the hope I stated above my disclaimer is actually the way things work, then I should have deconflicted my l2tp setup. The "correct" way to fix the problem is probably to change xl2tpd so that you can specify a source port, but I'd rather not maintain my own bespoke xl2tpd nor try to get it into the official source; my requirement is awfully niche. And I don't even know if the source port change will work! Anyway, that's the story. I hope it is interesting and/or that it inspires some kind of alternative solution! --T
