We are seeing issues with IPsec vpn between Vyatta and CISCO
From vyatta, we can see the packets count getting incremented when we initiate traffic. But the CISCO side end is not able to see packets getting decrypted ( I cant access CISCO device. But I got update from the support person at CISCO side that they do not see the packets )
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
1 up 900.0/0.0 aes256 sha1 no 1899 3600 all
2 up 0.0/0.0 aes256 sha1 no 2263 3600 all
3 up 0.0/0.0 aes256 sha1 no 1945 3600 all
4 up 0.0/0.0 aes256 sha1 no 2295 3600 all
5 up 0.0/0.0 aes256 sha1 no 2021 3600 all
6 up 0.0/0.0 aes256 sha1 no 2092 3600 all
You can see tunnel 1 getting incremented. Is there any way we can capture data packets in VPN tunnel?
Where there is a technical problem for a site to site VPN where you don’t control both ends, I’ve found it useful in almost all cases to setup a temporary VPN endpoint that you control, verify that your IPSEC is working correctly against that endpoint, and then go back to the other party and suggest you are certain something is working. Then it is a case of beating the other end over the head until they properly debug & troubleshoot their configuration.
You wouldn’t exert this kind of effort if there is no time, budget or other pressures, but in my role as a consultant, your customer doesn’t care who fixes it (blame games typically ensue), so I’ve had to go to those extra lengths to 100% rule out my config is bad
I’ve dealt with banks that do things like “well, we have 100’s of VPNs on this device, it can’t possibly be our end that is wrong”. But of course, it does end up being their end after they actually get over the possibility that they may have made a mistake and actually debug the problem
But I think tcpdump in tun0 doesnt work. I use IPsec tunnels. I believe tcpdump work if we have a VTI tunnel interface?
root@vyatta3:~# tcpdump -nn -i tun0
tcpdump: tun0: No such device exists
(SIOCGIFHWADDR: No such device)
root@vyatta3:~#
Thanks CGB.
I agree. I am sure the issue is with other end. But just wanted to have some kind of proof that packets are encrypted and entered in to VPN tunnel. Like tcpdump will show logs of source / destination and port. Also in general if we run a tcpdump on ipsec interface, we will be able to see the incoming VPN traffic, but we can’t see the out going VPN traffic. It would be good if we have some command or tool to capture the traffic of outgoing VPN.
If the VPN has never been up, and there is nothing else being routed out the ipsec tunnel, then you can ‘know’ the traffic is egress’ing your network by tcpdump’ing on the public interface. Generate a controlled packet (e.g. ping -c1 ) and you should see exactly one packet on UDP 500, 4500 or whatever towards the public IP of the other end. Will that help in ‘proving’ the traffic is being sent their way?
Thanks, I am able to see the ESP packets when I ran tcpdump. I can see data packets when I initiate traffic. There is no other traffic going on in this interface. So I can predict that it is the VPN traffic which I generated.
