On 11/Nov - 20:02, 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;
>
>
> > 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)?
I cannot answer 1) but for 2, after a quick look in the code, it will
just not compile. There is no priority support in the key handling code
of NetBSD.
Another solution is to use the 'tag' interface, but it looks like this
Kame extension has not been ported in fast_ipsec, and so it won't work
in NetBSD-6 (through it does not seem to hard to get it back). Other
issue is that I'm not completely sure about how standard is the tagging
process over the different packet filters.
Unfortunately, I don't have much idea about how to solve your issue.
--
Arnaud Degroote
Postdoc
RIA LAAS - CNRS
Attachment:
signature.asc
Description: Digital signature