On Wed, May 09, 2007 at 06:11:00PM -0000, pnjiiri2000 wrote:
> I'm having a problem trying to configure openswan (IPSec) on my linux
> box. The scenario is this
> 
> 10.0.0.1 --> 10.0.0.23<-->81.32.32.21 ---> Internet<-->roadwarrior
> VPN Gateway  Gateway performs NAT                      (Windows/Linux)
> Linux box    Linux Box 
> one nic      two nics   

Have a `tcpdump` sitting on '10.0.0.23<-->81.32.32.21' and sniffing on 
the interface towards 10.0.0.1. While you are pinging you should see ESP 
(IP proto 51) packets going to 10.0.0.1. If you're lucky and you see ESP 
packets going back from that box, then it's most likely your pong 
packets and you should see them on the roadwarrior box as well.

If you do not see ESP packets going to 10.0.0.1 and they do not start on 
the roadwarrior, it's most likely that the IKE handshake failed. Then 
you need to watch out for IKE packets on the UDP port specified in the 
config file. You'll find a good clue in the pluto log (possibly after 
increasing the loglevel). That also applies if you do not see a single 
UDP packet going out from the roadwarrior. 

If that handshake gets stuck (one party keeps resending) try to 
determine which packet it is. Most handshakes fail with the fifth and 
sixth packet, where the authentication is done. If it fails further down 
it's the network configuration.

If you're seeing ESP packets going to 10.0.0.1, but none come back, 
you'll most probably find a clue in the openswan or in the kernel logs 
(which IPSEC stack are you using, btw?). You may have possibly increase 
the kernel IPSEC loglevel to see something meaningful.

Dirk.
-- 
The truth is an offense, but not a sin

Reply via email to