Re: IPsec vs ssh

[Darren Reed <darrenr%netbsd.org@localhost>]

On 11/11/2013 7:49 AM, John Nemeth wrote:
> 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.

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;


> Also, just encrypting icmp is next to useless.

Encrypting only icmp is perfect for testing until the configuration
is correct and properly operationalised.

> } 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.

This is from setkey(8):
...
             -P direction [priority specification] discard
             -P direction [priority specification] none
             -P direction [priority specification] ipsec
             protocol/mode/src-dst/level [...]

             You must specify the direction of its policy as direction.
             Either out, in, or fwd can be used.

             priority specification is used to control the placement of the
             policy within the SPD.  Policy position is determined by a signed
             integer where higher priorities indicate the policy is placed
             closer to the beginning of the list and lower priorities indicate
             the policy is placed closer to the end of the list.  Policies
             with equal priorities are added at the end of groups of such
             policies.

             Priority can only be specified when setkey has been compiled
             against kernel headers that support policy priorities (Linux >=
             2.6.6).  If the kernel does not support priorities, a warning
             message will be printed the first time a priority specification
             is used.  Policy priority takes one of the following formats:

             {priority,prio} offset
                      offset is an integer in the range from -2147483647 to
                      214783648.

             {priority,prio} base {+,-} offset
                      base is either low (-1073741824), def (0), or high
                      (1073741824)

                      offset is an unsigned integer.  It can be up to
                      1073741824 for positive offsets, and up to 1073741823
                      for negative offsets.

             discard means the packet matching indexes will be discarded.
             none means that IPsec operation will not take place onto the
             packet.  ipsec means that IPsec operation will take place onto
             the packet.

...

Note that there are three possible actions per SPD: discard, ipsec and none.

So I'll return to the question:
1) why isn't "priority" supported?
2) what happens if I turn knobs to make it work (or try to)?

Darren