Re: IPsec vs ssh

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 12,  3:51am, Darren Reed wrote:
} On 11/11/2013 9:25 PM, John Nemeth wrote:
} ...
} > } Connectivity between the two endpoints exists well enough to support ssh
} > } between them.
} > } 
} > } If it helps, let me rewrite the above like this:
} > } 
} > } spdadd 203.33.153.28/32 10.1.1.0/24 icmp -P in ipsec 
esp/tunnel/203.33.153.28-10.1.1.1/require;
} > } spdadd 10.1.1.0/24 203.33.153.28/32 icmp -P out ipsec 
esp/tunnel/10.1.1.1-203.33.153.28/require;
} > 
} >      With a private address as one of the tunnel endpoints, are
} > you trying do to NAT-T?  Last I checked, that didn't work, and I
} > don't know if it has been fixed (there have been several attempts).
} > I'm assuming that you can ping from 10.1.1.1 to 203.33.153.28...
} 
} Yes, I'm trying to do NAT-T but I'm using KAME, not FAST_IPSEC.

     In my various tests, I've nevered had NAT-T work with either.
I will note that my tests were done with a Cisco router as the
remote endpoint.  Although not 100% certain, I believe NAT-T is
currently broken.

} > } > Also, just encrypting icmp is next to useless.
} > } 
} > } Encrypting only icmp is perfect for testing until the configuration
} > } is correct and properly operationalised.
} > 
} >      True enough.  Does the tunnel come up and work?  Can you ping
} > both directions through the tunnel?
} 
} Almost.

     Then this is the real problem:  you don't have a viable tunnel.

     You might want to use "setkey -D" and/or "setkey -D -P" to
see what the kernel is seeing.

}-- End of excerpt from Darren Reed