Randomize source port of UDP connection

Hi,

as far as i know, this is not possible. 

But tbh this sounds kinda odd, that your ISP is blocking those connections? 

Or do we talk about a new IP after the PPPoE Reconnect? 

Yeah this caused endless headaches until I figured out what was going on. I've seen it with a few ISP's and a few protocols, going back 10 years or more. Basically anything that uses fixed src/dst ports or protocols, so RED, SSL VPN (UDP), and IPSEC all have this problem.

My thinking is that the ISP's infrastructure does connection tracking, and the tracking exists against a PPPoE session. When the PPPoE session drops and a new one is established, any connections against the previous PPPoE session remain against the now-dropped session. The connection is identified by srcip+srcport + dstip+dstport. TCP connections are fine. - there is a new src port and all the right things happen.

This behaviour is desirable in some cases, but when the connection is like a RED connection where the srcip+srcport and dstip+dstport are all the same, the packets never make it through until I disable the RED server for >90 seconds.

The "stop all packets for >90 seconds" is the only thing in the above that I can tell you is fact. The rest is speculation on my part but i can't think of another cause.

So to give an example:

RED Client IP a.a.a.a + RED Server IP b.b.b.b is working fine. Then the Client PPPoE connection drops and then reestablishes within (say) 20 seconds.

The TCP control connection (TCP) from a.a.a.a->b.b.b.b connects just fine. The udp/3410 packets from b.b.b.b -> a.a.a.a never reach a.a.a.a though. A tcpdump at b.b.b.b shows that the packets are correctly sent, while a tcpdump at a.a.a.a shows nothing. The UDP traffic needs to completely cease for >90 seconds for the ISP to forget about the old connection and then everything works again.

My workaround so far has been to increase the PPPoE keepalives so that when the PPPoE connection drops, the Sophos doesn't know about it for enough time for the server to stop sending packets and let the connection drop. I've tried 5 minutes and that isn't long enough so far.

Randomizing the source port would work, but would have to happen as part of the RED protocol itself. I tried an SNAT rule on the client to do that, but RED seems to insert itself into the kernel network stack at a fairly low level and there is no rule about which end (client or server) sends the first packet, so it won't work.

James

I would simultaneously dump the XG site and do a RED Debugging on RED site. And confront the ISP with it. 

We cannot build up connections, if the ISP is dropping something. ISPs cannot do this at all. I highly doubt, there is something like Conntrack in place. So would instead refer to the ISP Support and escalate this topic to the ISP. 

I would simultaneously dump the XG site and do a RED Debugging on RED site. And confront the ISP with it. 

We cannot build up connections, if the ISP is dropping something. ISPs cannot do this at all. I highly doubt, there is something like Conntrack in place. So would instead refer to the ISP Support and escalate this topic to the ISP. 

I've tried going down that path and it just got too hard.

Most ISPs are moving away from PPPoE to IPoE and the problem disappears. This is not without its own problems though... at least one ISP is using giving CPE an address in a /24 space (253 customers per 256 addresses vs 64 if they use a /30).

So if customer A is assigned address 1.1.1.10/24, and customer B is assigned address 1.1.1.11/24, and customer B also has another service with address 2.2.2.2, then if customer A sends a packet from 1.1.1.10 to 2.2.2.2, the Sophos at customer B drops the packet because it arrives on the wrong subnet.

Bring on IPv6!

James