UDP reply packet's port is not equal to original dest port, this caused firewall drop this packet

[Hacksign]

Hi there,

What is the problem

This problem is found when I'm trying to setup an IPSec vpn. The reason causing this problem is because the reply packet's source port is not same as original incomimg dest port, so the firewall dropped the reply packet because the three tuple information are missmatched.

Logs

See tcpdump logs below:

Server side:

17:41:07.817589 pppoe-wan In  IP client-ip.32137 > server-ip.500: isakmp: parent_sa ikev2_init[I]
17:41:07.821927 lo    In  IP server-ip.500 > client-ip.32137: isakmp: parent_sa ikev2_init[R]
17:41:07.823584 pppoe-wan Out IP server-ip.50577 > client-ip.32137: UDP, length 38

Client side only saw the out going traffic to server-ip port 500, didnt see the reply packet.

Conclusion

So, here is the scene:

1. the original dest port is 500
2. then traffic is redirected to lo by TProxy
3. finally the reply is sending to client-ip.32137 with server-ip.50577

The reply is going out through port 50577 , this cuased client's firewall failing to match 3-tuples and drop this packet, this is why I can not see and reply packet in client side.

What I have done

My question is how can I avoiding this behaviour ? I have tried to:

1. disabling ipv4 tproxy at pppoe-wan interface
2. bypassing 500 port on outbound routing

Both are not able to resolve my problem ;(

[Hacksign]

This seems to be a plugin bug, XRAY supports bypass traffic by port.

Solution & analysis see this issue