Re: IPsec vs ssh

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

On Nov 11,  7:19am, Darren Reed wrote:
} On 11/11/2013 6:22 AM, John Nemeth wrote:
} > On Nov 11,  1:39am, Darren Reed wrote:
} > }
} > } I'm experimenting with IPsec and have found that once I have
} > } a tunnel working between a pair of NetBSD hosts running IPsec,
} > } I can no longer ssh directly from one to the other - or that
} > } once I load ipsec.conf, ssh sessions freeze.
} > } 
} > } The reason for this is that I suspect the SPD (ipsec.conf)
} > } ends up specifying that the packets for ssh between the two
} > } hosts are to be encrypted and wrapped up by each end point
} > } before being sent to the other end.
} > 
} >      All matching packets will be wrapped and tunneled.  However,
} > ssh isn't any different from any other TCP protocol in this regard.
} > This is NOT what's breaking ssh.  Since you didn't provide full
} > details, it isn't possible to determine what is wrong with your
} > config.
} 
} Really?

     Above you state that you suspect that IPSec is breaking ssh.
IPSec does NOT break ssh when correctly configured.

} The SPD lines that I am currently using are:
} 
} spdadd A.B.C.D/32 E.F.G.0/24 icmp -P in ipsec 
esp/tunnel/A.B.C.D-E.F.G.H/require;
} spdadd E.F.G.0/24 A.B.C.D/32 icmp -P out ipsec 
esp/tunnel/E.F.G.H-A.B.C.D/require;

     Last I checked, A.B.C.D and E.F.G.H are not valid IPv4 addresses.
Since you haven't provided an actual configuration, it is impossible
to determine what is wrong with your configuration.  Can't even
answer basic questions such as, is there connectivity between the
specified endpoints.  Also, just encrypting icmp is next to useless.

} And with that, established ssh sessions are not interrupted.

     The above doesn't do much.

} If I change "icmp" to "any", any currently established ssh
} sessions stop working.

     Off the top of my head, I'm not sure if this is something that
isn't possible or if it is due to incorrect configuration.  My gut
is telling me the latter since encapsulating packets is done at a
pretty low level of the network stack and shouldn't affect what
happens at the higher levels, other then a slight delay while the
tunnel is brought up.

} To be more precise, I don't want ssh packets to be handled

     Off the top of my head, I'm not sure how you would go about
excluding a single protocol.

} by IPsec because (a) there's no need to encrypt encrypted
} data and (b) it preserves ssh access irrespective of the
} status of IPsec. I'm not interested in arguing about the
} merits of this, this is the policy that I want to deploy
} and it seems like it should be possible. Question is,
} why can't I?
} 
} Darren
} 
}-- End of excerpt from Darren Reed