We have 3 Sophos's deployed, all with WAN connections with the same ISP. The WAN connections are all VDSL using PPPoE. I will call the routers A, B, and C.
A is the head office, as the RED server
B and C both have RED tunnels back to A
Initially, when the tunnels come up it works great. The C->A tunnel is reliable so far, but after a while, maybe 20-120 minutes, but then the B->A tunnel stops working and keeps going in a loop of trying to re-establish. If I drop the tunnel for a while it works again for a while. The B->A tunnel is under high load, pretty much saturated with traffic. I haven't checked the load on the C->A tunnel but it should be pretty much idle.
I have determined that the TCP connection to port 3400 from B to A is fine, but the UDP packets sent from B on port 3410 are not arriving on A.
tcpdump on B shows that the packets are seen on the WAN interface eth1_ppp interface, and are also seen on the eth1 interface (having been encapsulated inside PPPoE).
tcpdump on A shows that the packets are never received on the eth1 interface, where they should appear as PPPoE encapsulated packets.
I wrote some perl to send a udp packet (nc is crippled under XG) to port 3410 and this works when the source port is random, and it also works if I NAT the source port to a fixed port (not 3410), but if I NAT the source port to 3410 I get exactly the same thing - the packet leaves B but never arrives at A.
This feels exactly like the behaviour I would expect from a carrier grade DDoS or flood protection product - it detects a flood of UDP packets and blocks them until it hasn't seen any activity for a while. The ISP tells me that they have no such thing inside their network though.
Based on what i've described above, have I missed anything? I'm going to have to push fairly hard with the ISP support to get them to investigate any deeper, so I want to be sure that the blocking is happening at their end and that I haven't overlooked something at my end.
Thanks
James
This thread was automatically locked due to age.