1

I am having an issue with my smartphone device and packets monitoring: I am trying to find a reason why I cannot establish a VPN connection via PPTP protocol.

I have the following successful scenario:

  • Device set using IPv4
  • Connecting to VPN OK

Now a failing scenario:

  • Device set using IPv6
  • Connecting to VPN fails (after 30s timeout)

I checked tcpdump result and found out the following: during exchanges for connection establishment, both IPv6 and IPv4 scenario are the same until my device is sending a "PPP LCP Configuration-Request" to server.

Then a Ack comes back from server for IPv4 scenario, and nothing comes back for IPv6 scenario. On server side they affirm that in both scenario the Ack is send back.

Questions

  • If tcpdump does not show this packet, does that mean it has not been received ?
  • If this packet have been received but "dropped", how can I find out (tools, methodology) ?

I am not a Linux nor a network expert so I might miss some trivial hints.

Thanks,


Linux version 3.10.40

0

If tcpdump does not show this packet, does that mean it has not been received ?

Yes, that's what it means. Packet capture directly sees what's being received on the wire. If there were a firewall/filter rule dropping the packet, it would still show up in the packet capture and then it would be dropped at a later time.

Most likely something else somewhere along the network path is filtering the ConfAck. You could inquite whether the ConfAck in the IPv6 case is much larger than the ConfAck in the IPv4 case. I don't see why it would be, but if it were much bigger, enough to require fragmentation somewhere along the way due to an MTU issue, I guess that could cause the problem?

  • Thanks for the reply, I will investigate further by asking the server side tcpdump and checking the ConfAck size – csauvanet Apr 28 '15 at 14:20
  • This should be the good answer for general case, in my particular case it happens that architecture is XLAT64. So I have a Clat daemon doing the nat 4->6 translation, maybe there are some other explanation of loosing packets in that clat daemon ? I wonder if tcpdump should still see it or not. – csauvanet May 7 '15 at 7:57
  • @csauvanet I have no experience with XLAT64 but I can say that tcpdump will always show packets exactly as they are on the wire regardless of what happens afterwards, no exceptions... unless something happens in hardware. My quick reading of the information you linked suggests that I guess you'd see IPv6 on the wire and then it becomes IPv4 after it goes through the "clat" daemon so therefore if you tcpdump the wireless interface you'd see IPv6 and if you tcpdump the lo (loopback) interface you'd see IPv4. As I said though, no experience, so I probably haven't got it right. – Celada May 8 '15 at 0:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.