Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 6259 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos to Sophos RED tunnel blocked by ISP. Maybe.

jamesharper

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.
Parents
  • 0

    It occurred to me to try and reproduce this on another port.

    I wrote some perl to flood the WAN with packets on port 13410 (same src and dst port) from B to A.

    tcpdump shows around 38000 packets received then nothing further.

    Even though no further packets are being received at A, the link at B is still completely saturated, indicating that the packets are indeed leaving the router.

    I am also able to reproduce this from C to A.

    James

  • 0 in reply to jamesharper

    Hi,

    in my point of view, this could be a ISP Issue. Because if the (D)DOS Protection would block these 3410 Packets, they would at least arrive on the WAN Interface.

    The XG cannot block something, which won´t arrive on the interface level.

    We are using port 3400 to negotiate the tunnel and using 3410 for the data traffic. So maybe your ISP (or edge firewall before A?) is blocking something?

     

    Cheers

  • 0 in reply to LuCar Toni

    I did get to the bottom of this.

    High traffic was drowning out the PPPoE LCP ECHO packets, and so the link was getting dropped.

    This is speculation now, but it seems that when the link was dropped, for some reason the ISP router was tracking the connection against the old PPPoE instance, and not passing packets until the connection timed out.

    XG lacks the controls to properly QoS the PPPoE packets, but I have implemented enough limiting to control the situation without otherwise impacting performance too much.

    James

Reply
  • 0 in reply to LuCar Toni

    I did get to the bottom of this.

    High traffic was drowning out the PPPoE LCP ECHO packets, and so the link was getting dropped.

    This is speculation now, but it seems that when the link was dropped, for some reason the ISP router was tracking the connection against the old PPPoE instance, and not passing packets until the connection timed out.

    XG lacks the controls to properly QoS the PPPoE packets, but I have implemented enough limiting to control the situation without otherwise impacting performance too much.

    James

Children
No Data