Re: IPsec vs ssh

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

On Nov 11,  8:02pm, Darren Reed wrote:
} 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;

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

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

} > } 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)?

     I can't answer these questions.  Networking code is not my
area (I just use it, including IPSec); it's your area.

}-- End of excerpt from Darren Reed