IPsec vs ssh

[Darren Reed]

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.

The man page for setkey seems to suggest that there is a priority
mechanism that would allow me to create a "none" SPD for ssh
packets but setkey on NetBSD doesn't support this. If I understand
correctly, if it was present then I would do something like this:

spdadd A.B.C.D/32 E.F.G.0/24 any -P in priority low ipsec esp/tunnel/A.B.C.D-E.F.G.H/require;
spdadd E.F.G.0/24 A.B.C.D/32 any -P out priority low ipsec esp/tunnel/E.F.G.H-A.B.C.D/require;
spdadd A.B.C.D/32[22] E.F.G.0/24[any] tcp -P in priority high none;
spdadd E.F.G.0/24[any] A.B.C.D/32[22] tcp -P out priority high none;

So that the policy for packets matching ssh have a higher priority than
the others and result in no action being taken by IPsec with them.

Some questions..

1) How do I enable priority policies in NetBSD?
2) Will they work if I do enable them?
3) Is there another way to achieve this?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

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.

}-- End of excerpt from Darren Reed

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by John Nemeth
}
} 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?

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;

And with that, established ssh sessions are not interrupted.

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

To be more precise, I don't want ssh packets to be handled
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Darren Reed
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.

I'm tempted to tell you to stop being dense, but I don't know you well
enough to be sure that's what it is.

I think Darren is probably expecting the exception to apply not
strictly to ssh connections but rather to port-22 connections. I too
think doing anything of the sort for exactly ssh connections will be
very difficult, but port 22 should be relatively easy and, in most
cases, "port 22" is close enough to "ssh" for practical purposes, even
though neither actually strictly implies the other.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 10, 9:23pm, Mouse wrote:
}
} >> 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.
}
} I'm tempted to tell you to stop being dense, but I don't know you well
} enough to be sure that's what it is.
}
} I think Darren is probably expecting the exception to apply not
} strictly to ssh connections but rather to port-22 connections. I too

Well obviously, it would be port 22 traffic. That should go
without saying. Nevermind the lose usage of the word "protocol".
ssh is an application, not a protocol, if we want to use strict
networking terminology.

} think doing anything of the sort for exactly ssh connections will be
} very difficult, but port 22 should be relatively easy and, in most

So, where's your solution?

}-- End of excerpt from Mouse

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Nevermind the lose usage of the word "protocol". ssh is an
application, not a protocol, if we want to use strict networking
terminology.

It's also a protocol, or rather two related protocols (or two different
versions of a single protocol, if you prefer to think of it that way).
See RFCs 4250 through 4254 (and a few others, eg 4335) for the more
recent of the two; as far as I know the older is documented only in
source code.

Post by Mouse
think doing anything of the sort for exactly ssh connections will be
very difficult, but port 22 should be relatively easy

So, where's your solution?

Oh, I don't have one. My experience with IPsec consists of turning on
the "use IPsec" bit in a VPN appliance back a decade or so ago. My
"should be" was in the sense of "if it isn't then the design or
implementation is pretty catastrophically broken" than in the sense of
"here's how to do it". I wouldn't have written at all except for what
looked like quibbling about the difference between "ssh" and "port 22".

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by John Nemeth
} > }
} > } 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.
}
} 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;

Post by John Nemeth
Also, just encrypting icmp is next to useless.

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

Post by John Nemeth
} 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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

On 11/11/2013 9:25 PM, John Nemeth wrote:
...

Post by John Nemeth
} Connectivity between the two endpoints exists well enough to support ssh
} between them.
}
}
} 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.

Post by John Nemeth
} > 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.

I've got a pair of hosts using a full SPD like this:

spdadd 10.1.2.254/24 10.1.3.0/24 any -P out ipsec esp/tunnel/10.1.2.254-203.33.153.28/require;
spdadd 10.1.3.0/24 10.1.2.0.254/32 any -P in ipsec esp/tunnel/203.33.153.28-10.1.2.254/require;

spdadd 203.33.153.28/32 10.1.1.0/24 icmp -P in ipsec esp/tunnel/203.33.153.28-10.1.2.254/require;
spdadd 10.1.1.0/24 203.33.153.28/32 icmp -P out ipsec esp/tunnel/10.1.2.254-203.33.153.28/require;

spdadd 10.1.3.0/24 10.1.1.0/24 any -P in ipsec esp/tunnel/203.33.153.28[4500]-10.1.2.254[4500]/require;
spdadd 10.1.1.0/24 10.1.3.0/24 any -P out ipsec esp/tunnel/10.1.2.254[4500]-203.33.153.28[4500]/require;

For now, with racoon I'm using both "remote anonymous" and "sainfo anonymous".

It all goes well until this locally:

DEBUG: Either family (2 - 2), types (1 - 0) of ID from initiator differ or matching sainfo has no id_i defined for the peer. Not filling iph2->sa_src and iph2->sa_dst.
DEBUG: get src address from ID payload 10.1.2.254[0] prefixlen=32 ul_proto=255
DEBUG: get dst address from ID payload 10.1.1.0[0] prefixlen=24 ul_proto=255
DEBUG: sub:0xbfbfe288: 10.1.2.254/32[0] 10.1.1.0/24[0] proto=any dir=in
DEBUG: db :0xbb661078: 10.1.2.254/24[0] 10.1.3.0/24[0] proto=any dir=out
DEBUG: sub:0xbfbfe288: 10.1.2.254/32[0] 10.1.1.0/24[0] proto=any dir=in
DEBUG: db: 0xbb661078: 10.1.2.254/24[0] 10.1.3.0/24[0] proto=any dir=out
DEBUG: sub:0xbfbfe288: 10.1.2.254/32[0] 10.1.1.0/24[0] proto=any dir=in
DEBUG: db :0xbb6611a8: 10.1.3.0/24[0] 10.1.2.254/32[0] proto=any dir=in
DEBUG: sub:0xbfbfe288: 10.1.2.254/32[0] 10.1.1.0/24[0] proto=any dir=in
DEBUG: db: 0xbb6611a8: 10.1.3.0/24[0] 10.1.2.254/32[0] proto=any dir=in
DEBUG: 0xbfbfe288 masked with /24: 10.1.2.0[0]
DEBUG: 0xbb6611a8 masked with /24: 10.1.3.0[0]
ERROR: no policy found: 10.1.2.254/32[0] 10.1.1.0/24[0] proto=any dir=in
ERROR: failed to get proposal for responder.
[203.33.153.28] ERROR: failed to pre-process ph2 packet (side: 1, status: 1).
DEBUG: IV freed

At which point ping packets go out from the netbsd box at the other end,
get decrypted, received, replied to, reply comes back encrypted and is then
dropped due to a missing SPI.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by John Nemeth
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.

I beg to differ. I am using xl2tpd (from pkgsrc) with IPSEC/NAT-T
to provide an L2TP gateway for my iphone and MacOS/X box and it works
just fine (under /current). I bet android and windows are simple to
get working too.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 11, 10:05pm, Christos Zoulas wrote:
} In article <***@server.cornerstoneservice.ca>,
} John Nemeth <***@cue.bc.ca> wrote:
} >
} > 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.
}
} I beg to differ. I am using xl2tpd (from pkgsrc) with IPSEC/NAT-T
} to provide an L2TP gateway for my iphone and MacOS/X box and it works
} just fine (under /current). I bet android and windows are simple to
} get working too.

This sound like the NetBSD side has a public address and is
acting as the "server". What happens if the NetBSD side has a
private address?

}-- End of excerpt from Christos Zoulas

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Nov 11, 2:18pm, ***@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: IPsec vs ssh

| } I beg to differ. I am using xl2tpd (from pkgsrc) with IPSEC/NAT-T
| } to provide an L2TP gateway for my iphone and MacOS/X box and it works
| } just fine (under /current). I bet android and windows are simple to
| } get working too.
|
| This sound like the NetBSD side has a public address and is
| acting as the "server". What happens if the NetBSD side has a
| private address?

I will try and let you know. You want the NetBSD side to be behind NAT,
and NetBSD to be initiating the connection, right?

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 11, 5:33pm, Christos Zoulas wrote:
} On Nov 11, 2:18pm, ***@cue.bc.ca (John Nemeth) wrote:
}
} | } I beg to differ. I am using xl2tpd (from pkgsrc) with IPSEC/NAT-T
} | } to provide an L2TP gateway for my iphone and MacOS/X box and it works
} | } just fine (under /current). I bet android and windows are simple to
} | } get working too.
} |
} | This sound like the NetBSD side has a public address and is
} | acting as the "server". What happens if the NetBSD side has a
} | private address?
}
} I will try and let you know. You want the NetBSD side to be behind NAT,
} and NetBSD to be initiating the connection, right?

Yep. Would be kind of hard for the other side to initiate
the connection. :-> Of course, Darren said he was using KAME,
and you would be using FAST_IPSEC given that KAME was removed from
-current. So even if your test passes (which would be good news),
it doesn't mean that Darren's setup would work. I could update my
laptop and try, but it would probably be a few days for me to build,
install, and test.

}-- End of excerpt from Christos Zoulas

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

On 12/11/2013 7:48 AM, John Nemeth wrote:
...

Post by John Nemeth
} > } > 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.

Why do I need a tunnel?

Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 12, 12:28pm, Darren Reed wrote:
} On 12/11/2013 7:48 AM, John Nemeth wrote:
} ...
} > } > } > 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.
}
} Why do I need a tunnel?

A tunnel is basically encapsulation of any sort. So, when you
encapsulate any of kind of packet with an IPSec (ESP) wrapper, you
have essentially created a tunnel.

}-- End of excerpt from Darren Reed

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by John Nemeth
} ...
} > } > } > 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.
}
} Why do I need a tunnel?
A tunnel is basically encapsulation of any sort. So, when you
encapsulate any of kind of packet with an IPSec (ESP) wrapper, you
have essentially created a tunnel.

Ah, ok, then yes, the tunnel is created by the SPD in ipsec.conf.
I wasn't sure if you were referring to a gif, etc, style of tunnel.

FWIW, I get 3 out of 4 "IPsec-SA established" messages. Unfortunately
unless you get all four, it does not work.

Kind Regards,
Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Darren Reed

Post by John Nemeth
A tunnel is basically encapsulation of any sort. So, when you
encapsulate any of kind of packet with an IPSec (ESP) wrapper, you
have essentially created a tunnel.

If you use tunnel mode, yes. One can also use transport mode, where
IP:TCP is replaced by IP:ESP[TCP] (note that there is no outer header and
the original header is not inside the ESP payload. But in the modern
world, that's odd.

Post by Darren Reed
Ah, ok, then yes, the tunnel is created by the SPD in ipsec.conf.
I wasn't sure if you were referring to a gif, etc, style of tunnel.

Exactly; it's internal to the IPsec implementation.

Post by Darren Reed
FWIW, I get 3 out of 4 "IPsec-SA established" messages. Unfortunately
unless you get all four, it does not work.

That's a huge clue. I would turn up racoon debugging.

[Darren Reed]

Post by Greg Troxel

Post by Darren Reed

Post by John Nemeth
A tunnel is basically encapsulation of any sort. So, when you
encapsulate any of kind of packet with an IPSec (ESP) wrapper, you
have essentially created a tunnel.

If you use tunnel mode, yes. One can also use transport mode, where
IP:TCP is replaced by IP:ESP[TCP] (note that there is no outer header and
the original header is not inside the ESP payload. But in the modern
world, that's odd.

Post by Darren Reed
Ah, ok, then yes, the tunnel is created by the SPD in ipsec.conf.
I wasn't sure if you were referring to a gif, etc, style of tunnel.

Exactly; it's internal to the IPsec implementation.

Post by Darren Reed
FWIW, I get 3 out of 4 "IPsec-SA established" messages. Unfortunately
unless you get all four, it does not work.

That's a huge clue. I would turn up racoon debugging.

I have and it isn't really helping.

I'm starting to suspect there is a bug in racoon and that I'm going
to have to go digging. What appears to go wrong is that when it adds
the second SA.

e.g. racoon logs for just messages with "pfkey" in them:

Remote host:
/tmp/rac.log.0:DEBUG: call pfkey_send_register for AH
/tmp/rac.log.0:DEBUG: call pfkey_send_register for ESP
/tmp/rac.log.0:DEBUG: call pfkey_send_register for IPCOMP
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: get pfkey X_SPDDUMP message
/tmp/rac.log.0:DEBUG: call pfkey_send_dump
/tmp/rac.log.0:DEBUG: call pfkey_send_getspi
/tmp/rac.log.0:DEBUG: pfkey GETSPI sent: ESP/Tunnel 128.250.34.26[4500]->10.1.3.254[4500]
/tmp/rac.log.0:DEBUG: pfkey getspi sent.
/tmp/rac.log.0:DEBUG: get pfkey GETSPI message
/tmp/rac.log.0:DEBUG: pfkey GETSPI succeeded: ESP/Tunnel 128.250.34.26[4500]->10.1.3.254[4500] spi=225908429(0xd7716cd)
/tmp/rac.log.0:DEBUG: call pfkey_send_update2
/tmp/rac.log.0:DEBUG: pfkey update sent.
/tmp/rac.log.0:DEBUG: call pfkey_send_add2 (NAT flavor)
/tmp/rac.log.0:DEBUG: call pfkey_send_add2
/tmp/rac.log.0:DEBUG: pfkey add sent.
/tmp/rac.log.0:DEBUG: get pfkey UPDATE message
/tmp/rac.log.0:DEBUG: pfkey UPDATE succeeded: ESP/Tunnel 128.250.34.26[4500]->10.1.3.254[4500] spi=225908429(0xd7716cd)
/tmp/rac.log.0:DEBUG: get pfkey ADD message
/tmp/rac.log.0:DEBUG: get pfkey FLUSH message
/tmp/rac.log.0:DEBUG: call pfkey_send_dump

Local host:
/tmp/rac.log.2:DEBUG: call pfkey_send_register for AH
/tmp/rac.log.2:DEBUG: call pfkey_send_register for ESP
/tmp/rac.log.2:DEBUG: call pfkey_send_register for IPCOMP
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey X_SPDDUMP message
/tmp/rac.log.2:DEBUG: got pfkey ACQUIRE message
/tmp/rac.log.2:DEBUG: call pfkey_send_dump
/tmp/rac.log.2:DEBUG: call pfkey_send_getspi
/tmp/rac.log.2:DEBUG: pfkey GETSPI sent: ESP/Tunnel 141.161.4.77[4500]->10.1.3.254[4500]
/tmp/rac.log.2:DEBUG: pfkey getspi sent.
/tmp/rac.log.2:DEBUG: got pfkey GETSPI message
/tmp/rac.log.2:DEBUG: pfkey GETSPI succeeded: ESP/Tunnel 141.161.4.77[500]->10.1.3.254[500] spi=70491361(0x4339ce1)
/tmp/rac.log.2:DEBUG: call pfkey_send_update2
/tmp/rac.log.2:DEBUG: pfkey update sent.
/tmp/rac.log.2:DEBUG: call pfkey_send_add2 (NAT flavor)
/tmp/rac.log.2:DEBUG: call pfkey_send_add2
/tmp/rac.log.2:DEBUG: pfkey add sent.
/tmp/rac.log.2:DEBUG: got pfkey UPDATE message
/tmp/rac.log.2:ERROR: pfkey UPDATE failed: No such file or directory
/tmp/rac.log.2:DEBUG: got pfkey ADD message

I suspect that there is either something wrong with the PF_KEY
message generated for "pfkey add sent." or the following update
message. The two versions of racoon are not the same - one is
the "rewrite" (doesn't work) and one is an older version (works).

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Darren Reed
/tmp/rac.log.2:DEBUG: pfkey GETSPI sent: ESP/Tunnel
141.161.4.77[4500]->10.1.3.254[4500]
/tmp/rac.log.2:DEBUG: pfkey getspi sent.
/tmp/rac.log.2:DEBUG: got pfkey GETSPI message
/tmp/rac.log.2:DEBUG: pfkey GETSPI succeeded: ESP/Tunnel
141.161.4.77[500]->10.1.3.254[500] spi=70491361(0x4339ce1)
/tmp/rac.log.2:DEBUG: call pfkey_send_update2
/tmp/rac.log.2:DEBUG: pfkey update sent.
/tmp/rac.log.2:DEBUG: call pfkey_send_add2 (NAT flavor)
/tmp/rac.log.2:DEBUG: call pfkey_send_add2
/tmp/rac.log.2:DEBUG: pfkey add sent.
/tmp/rac.log.2:DEBUG: got pfkey UPDATE message
/tmp/rac.log.2:ERROR: pfkey UPDATE failed: No such file or directory
/tmp/rac.log.2:DEBUG: got pfkey ADD message
I suspect that there is either something wrong with the PF_KEY
message generated for "pfkey add sent." or the following update
message. The two versions of racoon are not the same - one is
the "rewrite" (doesn't work) and one is an older version (works).

Agreed; this looks like the spot. Use 'setkey -x' to dump the message.
It's possible racoon is not consistently handling the NAT part.

[Darren Reed]

On 14/11/2013 12:23 AM, Greg Troxel wrote:
...

Post by Greg Troxel
Agreed; this looks like the spot. Use 'setkey -x' to dump the message.
It's possible racoon is not consistently handling the NAT part.

Interesting output...

The error is in an UPDATE message that follows a GETSPI message,
both with the same SPI. That agrees with the earlier logs.

Now that I notice it, the GETSPI message prints port 500 but everywhere
else is 4500.

Also, setkey -x needs to learn about SADB_X_EXT_NAT_T_FRAG.

Darren

06:22:40.895815
sadb_msg{ version=2 type=11 errno=0 satype=1 len=2 reserved=0 seq=0 pid=19186

06:22:40.895908
06:22:42.533802
sadb_msg{ version=2 type=7 errno=0 satype=2 len=21 reserved=0 seq=0 pid=13808
sadb_ext{ len=11 type=14 }
sadb_sup{
{ id=2 ivlen=0 min=128 max=128 }
{ id=3 ivlen=0 min=160 max=160 }
{ id=5 ivlen=0 min=256 max=256 }
{ id=6 ivlen=0 min=384 max=384 }
{ id=7 ivlen=0 min=512 max=512 }
{ id=8 ivlen=0 min=160 max=160 }
{ id=9 ivlen=0 min=128 max=128 }
{ id=249 ivlen=0 min=128 max=128 }
{ id=250 ivlen=0 min=160 max=160 }
{ id=251 ivlen=0 min=0 max=2048 }
}
sadb_ext{ len=8 type=15 }
sadb_sup{
{ id=2 ivlen=8 min=64 max=64 }
{ id=3 ivlen=8 min=192 max=192 }
{ id=6 ivlen=8 min=40 max=128 }
{ id=7 ivlen=8 min=40 max=448 }
{ id=11 ivlen=0 min=0 max=2048 }
{ id=12 ivlen=16 min=128 max=256 }
{ id=13 ivlen=8 min=160 max=288 }
}

06:22:42.534497
sadb_msg{ version=2 type=7 errno=0 satype=3 len=21 reserved=0 seq=0 pid=13808
sadb_ext{ len=11 type=14 }
sadb_sup{
{ id=2 ivlen=0 min=128 max=128 }
{ id=3 ivlen=0 min=160 max=160 }
{ id=5 ivlen=0 min=256 max=256 }
{ id=6 ivlen=0 min=384 max=384 }
{ id=7 ivlen=0 min=512 max=512 }
{ id=8 ivlen=0 min=160 max=160 }
{ id=9 ivlen=0 min=128 max=128 }
{ id=249 ivlen=0 min=128 max=128 }
{ id=250 ivlen=0 min=160 max=160 }
{ id=251 ivlen=0 min=0 max=2048 }
}
sadb_ext{ len=8 type=15 }
sadb_sup{
{ id=2 ivlen=8 min=64 max=64 }
{ id=3 ivlen=8 min=192 max=192 }
{ id=6 ivlen=8 min=40 max=128 }
{ id=7 ivlen=8 min=40 max=448 }
{ id=11 ivlen=0 min=0 max=2048 }
{ id=12 ivlen=16 min=128 max=256 }
{ id=13 ivlen=8 min=160 max=288 }
}

06:22:42.535123
sadb_msg{ version=2 type=7 errno=0 satype=9 len=21 reserved=0 seq=0 pid=13808
sadb_ext{ len=11 type=14 }
sadb_sup{
{ id=2 ivlen=0 min=128 max=128 }
{ id=3 ivlen=0 min=160 max=160 }
{ id=5 ivlen=0 min=256 max=256 }
{ id=6 ivlen=0 min=384 max=384 }
{ id=7 ivlen=0 min=512 max=512 }
{ id=8 ivlen=0 min=160 max=160 }
{ id=9 ivlen=0 min=128 max=128 }
{ id=249 ivlen=0 min=128 max=128 }
{ id=250 ivlen=0 min=160 max=160 }
{ id=251 ivlen=0 min=0 max=2048 }
}
sadb_ext{ len=8 type=15 }
sadb_sup{
{ id=2 ivlen=8 min=64 max=64 }
{ id=3 ivlen=8 min=192 max=192 }
{ id=6 ivlen=8 min=40 max=128 }
{ id=7 ivlen=8 min=40 max=448 }
{ id=11 ivlen=0 min=0 max=2048 }
{ id=12 ivlen=16 min=128 max=256 }
{ id=13 ivlen=8 min=160 max=288 }
}

06:22:42.535791
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=5 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010200 }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a0103fe }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=1 id=4016 }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=0 8da1044d }
sockaddr{ len=16 family=2 port=0 0a0103fe }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:42.535839
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=4 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 8da1044d }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010100 }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=1 id=4017 }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=0 8da1044d }
sockaddr{ len=16 family=2 port=0 0a0103fe }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:42.535864
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=3 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010200 }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010100 }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=1 id=4019 }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=4500 8da1044d }
sockaddr{ len=16 family=2 port=4500 0a0103fe }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:42.535889
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=2 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a0103fe }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010200 }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=2 id=4015 }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=0 0a0103fe }
sockaddr{ len=16 family=2 port=0 8da1044d }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:42.535913
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=1 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010100 }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 8da1044d }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=2 id=4018 }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=0 0a0103fe }
sockaddr{ len=16 family=2 port=0 8da1044d }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:42.535937
sadb_msg{ version=2 type=18 errno=0 satype=0 len=23 reserved=1 seq=0 pid=13808
sadb_ext{ len=3 type=5 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010100 }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=1 prefixlen=24 reserved=0x0000 }
sockaddr{ len=16 family=2 port=0 0a010200 }
sadb_ext{ len=7 type=18 }
sadb_x_policy{ type=2 dir=2 id=401a }
{ len=40 proto=50 mode=2 level=2 reqid=0
sockaddr{ len=16 family=2 port=4500 0a0103fe }
sockaddr{ len=16 family=2 port=4500 8da1044d }
}
sadb_ext{ len=4 type=2 }
sadb_lifetime{ alloc=0, bytes=0 addtime=1384370551, usetime=1384370551 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 }

06:22:45.453075
sadb_msg{ version=2 type=6 errno=0 satype=3 len=47 reserved=0 seq=3 pid=0
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=2 type=18 }
sadb_x_policy{ type=2 dir=2 id=401a }
sadb_ext{ len=37 type=13 }
sadb_prop{ replay=32
sadb_comb{ auth=0 encrypt=7 flags=0x0000 reserved=0x00000000
auth_minbits=0 auth_maxbits=0 encrypt_minbits=256 encrypt_maxbits=448
soft_alloc=1 hard_alloc=1 soft_bytes=0 hard_bytes=0
soft_alloc=69120 hard_alloc=86400 soft_bytes=23040 hard_bytes=28800 }
sadb_comb{ auth=0 encrypt=11 flags=0x0000 reserved=0x00000000
auth_minbits=0 auth_maxbits=0 encrypt_minbits=256 encrypt_maxbits=2048
soft_alloc=1 hard_alloc=1 soft_bytes=0 hard_bytes=0
soft_alloc=69120 hard_alloc=86400 soft_bytes=23040 hard_bytes=28800 }
sadb_comb{ auth=0 encrypt=12 flags=0x0000 reserved=0x00000000
auth_minbits=0 auth_maxbits=0 encrypt_minbits=256 encrypt_maxbits=256
soft_alloc=1 hard_alloc=1 soft_bytes=0 hard_bytes=0
soft_alloc=69120 hard_alloc=86400 soft_bytes=23040 hard_bytes=28800 }
sadb_comb{ auth=0 encrypt=13 flags=0x0000 reserved=0x00000000
auth_minbits=0 auth_maxbits=0 encrypt_minbits=256 encrypt_maxbits=288
soft_alloc=1 hard_alloc=1 soft_bytes=0 hard_bytes=0
soft_alloc=69120 hard_alloc=86400 soft_bytes=23040 hard_bytes=28800 }
}

06:22:46.025902
sadb_msg{ version=2 type=10 errno=2 satype=0 len=2 reserved=0 seq=0 pid=13808

DEBUG: pfkey GETSPI succeeded: ESP/Tunnel 141.161.4.77[500]->10.1.3.254[500] spi=192737835(0xb7cf22b)
06:22:46.477581
sadb_msg{ version=2 type=1(GETSPI) errno=0 satype=3 len=10 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=192737835 replay=64 state=6 auth=76 encrypt=125 flags=0xfe01a8c0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }

ERROR: pfkey UPDATE failed: No such file or directory
06:22:46.736242
sadb_msg{ version=2 type=2(UPDATE) errno=2 satype=3 len=31 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=192737835 replay=4 state=0 auth=3 encrypt=12 flags=0x00000000 }
sadb_ext{ len=2 type=19 }
sadb_x_sa2{ mode=2 reqid=0 reserved1=0 reserved2=0 sequence=0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }
sadb_ext{ len=3 type=9 }
sadb_key{ bits=128 reserved=0 key= 00000000 00000000 80700000 00000000 }
sadb_ext{ len=4 type=8 }
sadb_key{ bits=160 reserved=0 key= 04000400 00000000 00000000 00000000 005a0000 }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=28800, usetime=0 }
sadb_ext{ len=4 type=4 }
sadb_lifetime{ alloc=0, bytes=0 addtime=23040, usetime=0 }
sadb_ext{ len=1 type=20 }
sadb_x_nat_t_type{ type=2 }
sadb_ext{ len=1 type=21 }
sadb_x_nat_t_port{ port=4500 }
sadb_ext{ len=1 type=22 }
sadb_x_nat_t_port{ port=4500 }
sadb_ext{ len=1 type=25 }
kdebug_sadb: invalid ext_type 25 was passed.

06:22:46.738022
sadb_msg{ version=2 type=3(ADD) errno=0 satype=3 len=20 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=143351065 replay=4 state=0 auth=3 encrypt=12 flags=0x00000000 }
sadb_ext{ len=2 type=19 }
sadb_x_sa2{ mode=2 reqid=0 reserved1=0 reserved2=0 sequence=0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=28800, usetime=0 }
sadb_ext{ len=4 type=4 }
sadb_lifetime{ alloc=0, bytes=0 addtime=23040, usetime=0 }

06:22:46.738322
sadb_msg{ version=2 type=3(ADD) errno=0 satype=3 len=20 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=143351065 replay=4 state=0 auth=3 encrypt=12 flags=0x00000000 }
sadb_ext{ len=2 type=19 }
sadb_x_sa2{ mode=2 reqid=0 reserved1=0 reserved2=0 sequence=0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=4 type=3 }
sadb_lifetime{ alloc=0, bytes=0 addtime=28800, usetime=0 }
sadb_ext{ len=4 type=4 }
sadb_lifetime{ alloc=0, bytes=0 addtime=23040, usetime=0 }


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[SUENAGA Hiroki]

Post by Darren Reed
06:22:46.477581
sadb_msg{ version=2 type=1(GETSPI) errno=0 satype=3 len=10 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=192737835 replay=64 state=6 auth=76 encrypt=125 flags=0xfe01a8c0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }

this GETSPI message lacks NAT-T-TYPE and NAT-T-PORT payloads,
though the UPDATE message has NAT-T payloads. I think this
is incorrect message sequence.

original racoon adds the NAT-T payloads around here.

(racoon/pfkey.c)
894 int
895 pk_sendgetspi(iph2)
896 struct ph2handle *iph2;
897 {
...
957 #ifdef ENABLE_NATT
958 if (pr->udp_encap) {
959 natt_type = iph2->ph1->natt_options->encaps_type;
960 sport=extract_port(src);
961 dport=extract_port(dst);
962 }
963 #endif
...
966 if (pfkey_send_getspi_nat(
967 lcconf->sock_pfkey,
968 satype,
969 mode,
970 dst, /* src of SA */
971 src, /* dst of SA */
972 natt_type,
973 dport,
974 sport,
...

----------
Internet Initiative Japan Inc.

Management Service Section,
Product Development Department,
Product Division,
Technology Unit

SUENAGA Hiroki <***@iij.ad.jp>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by SUENAGA Hiroki

Post by Darren Reed
06:22:46.477581
sadb_msg{ version=2 type=1(GETSPI) errno=0 satype=3 len=10 reserved=0 seq=3 pid=13808
sadb_ext{ len=2 type=1 }
sadb_sa{ spi=192737835 replay=64 state=6 auth=76 encrypt=125 flags=0xfe01a8c0 }
sadb_ext{ len=3 type=5 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 8da1044d }
sadb_ext{ len=3 type=6 }
sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
sockaddr{ len=16 family=2 port=4500 0a0103fe }

this GETSPI message lacks NAT-T-TYPE and NAT-T-PORT payloads,
though the UPDATE message has NAT-T payloads. I think this
is incorrect message sequence.
original racoon adds the NAT-T payloads around here.
(racoon/pfkey.c)
894 int
895 pk_sendgetspi(iph2)
896 struct ph2handle *iph2;
897 {
...
957 #ifdef ENABLE_NATT
958 if (pr->udp_encap) {
959 natt_type = iph2->ph1->natt_options->encaps_type;
960 sport=extract_port(src);
961 dport=extract_port(dst);
962 }
963 #endif
...
966 if (pfkey_send_getspi_nat(
967 lcconf->sock_pfkey,
968 satype,
969 mode,
970 dst, /* src of SA */
971 src, /* dst of SA */
972 natt_type,
973 dport,
974 sport,

So the racoon in -current has "pr->udp_encap == 0" when it gets here.

This might be related to this message:

INFO: Adjusting my encmode UDP-Tunnel->Tunnel
INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)

So now I learn something interesting about ipsec.conf: the port
specifier does not support different policies, e.g. you cannot
have:

spadd 1.1.1.0/24 1.1.1.2/24 udp -P in esp/tunnel/2.2.2.2[4500]-3.3.3.3[4500]/require;
spadd 1.1.1.0/24 1.1.1.2/24 udp -P in esp/tunnel/2.2.2.2[500]-3.3.3.3[500]/require;

Turning "nat_traversal" off in racoon.conf makes less things work.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by John Nemeth
} ...
} > } > } > 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.
}
} Why do I need a tunnel?
A tunnel is basically encapsulation of any sort. So, when you

Wrong, wrong, wrong. IPsec has separate tunnel and transport modes.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 14, 8:27pm, Thor Lancelot Simon wrote:
} On Mon, Nov 11, 2013 at 05:40:44PM -0800, John Nemeth wrote:
} > On Nov 12, 12:28pm, Darren Reed wrote:
} > } On 12/11/2013 7:48 AM, John Nemeth wrote:
} > } ...
} > } > } > } > 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.
} > }
} > } Why do I need a tunnel?
} >
} > A tunnel is basically encapsulation of any sort. So, when you
}
} Wrong, wrong, wrong. IPsec has separate tunnel and transport modes.

If you had been following the thread, and seen the configuration
examples you would have seen that he was using IPSec in tunnel
mode. Transport mode, of course, doesn't encapsulate the packet;
it simply adds an ESP header (and encrypts the data portion) or an
AH header. Regardless of this, the statement that, "A tunnel is
basically encapsulation of any sort," stands on it's own, and is
correct. NOT WRONG!!!

}-- End of excerpt from Thor Lancelot Simon

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by John Nemeth
} >
} > A tunnel is basically encapsulation of any sort. So, when you
}
} Wrong, wrong, wrong. IPsec has separate tunnel and transport modes.
If you had been following the thread, and seen the configuration
examples you would have seen that he was using IPSec in tunnel
mode. Transport mode, of course, doesn't encapsulate the packet;
it simply adds an ESP header (and encrypts the data portion) or an
AH header. Regardless of this, the statement that, "A tunnel is
basically encapsulation of any sort," stands on it's own, and is
correct. NOT WRONG!!!

I'm sorry you're upset, but what you said was still incorrect, and
shouting about it strikes me as vaguely like spitting at the sky because
it's raining.

IPsec transport-mode encapsulation is not "a tunnel" by any reasonable
definition of "a tunnel" I can think of. Neither is the encapsulation
of TCP in IPv4 nor in IPv6. Encapsulating a Mifare RFID tag in a glass
bead for injection under the skin of a cat, similarly, is not a tunnel.

Indeed, the only sort of rationale I can think of to support the claim
that "a tunnel is basically encapsulation of any sort" is one of the
form "because a tunnel is basically encapsulation of any sort". But,
for one reason or another, I do not find that terribly persuasive.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Nov 15, 7:42am, Thor Lancelot Simon wrote:
} On Fri, Nov 15, 2013 at 12:00:07AM -0800, John Nemeth wrote:
} > } >
} > } > A tunnel is basically encapsulation of any sort. So, when you
} > }
} > } Wrong, wrong, wrong. IPsec has separate tunnel and transport modes.
} >
} > If you had been following the thread, and seen the configuration
} > examples you would have seen that he was using IPSec in tunnel
} > mode. Transport mode, of course, doesn't encapsulate the packet;
} > it simply adds an ESP header (and encrypts the data portion) or an
} > AH header. Regardless of this, the statement that, "A tunnel is
} > basically encapsulation of any sort," stands on it's own, and is
} > correct. NOT WRONG!!!
}
} I'm sorry you're upset, but what you said was still incorrect, and
} shouting about it strikes me as vaguely like spitting at the sky because
} it's raining.
}
} IPsec transport-mode encapsulation is not "a tunnel" by any reasonable
} definition of "a tunnel" I can think of. Neither is the encapsulation

The only person talking about IPSec transport mode is you.
As I said, transport mode does not encapsulate the packet (at least
not in the sense that you take an entire intact packet and stuff
it inside a new packet as the data portion), thus obviously, it is
not a tunnel.

}-- End of excerpt from Thor Lancelot Simon

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

So the SPD problem was solved by changing all of the "any" fields to "icmp":


spdadd 10.1.2.254/24 10.1.3.0/24 icmp -P out ipsec esp/tunnel/10.1.2.254-203.33.153.28/require;
spdadd 10.1.3.0/24 10.1.2.0.254/32 icmp -P in ipsec esp/tunnel/203.33.153.28-10.1.2.254/require;

spdadd 203.33.153.28/32 10.1.1.0/24 icmp -P in ipsec esp/tunnel/203.33.153.28-10.1.2.254/require;
spdadd 10.1.1.0/24 203.33.153.28/32 icmp -P out ipsec esp/tunnel/10.1.2.254-203.33.153.28/require;

spdadd 10.1.3.0/24 10.1.1.0/24 icmp -P in ipsec esp/tunnel/203.33.153.28[4500]-10.1.2.254[4500]/require;
spdadd 10.1.1.0/24 10.1.3.0/24 icmp -P out ipsec esp/tunnel/10.1.2.254[4500]-203.33.153.28[4500]/require;


But I still get this from the kernel:
/netbsd: IPv4 ESP input: no key association found for spi 208200261

DEBUG: call pfkey_send_add2 (NAT flavor)
DEBUG: call pfkey_send_add2
DEBUG: pfkey add sent.
DEBUG: pk_recv: retry[0] recv()
DEBUG: got pfkey UPDATE message
DEBUG2:
[hexdump]
ERROR: pfkey UPDATE failed: No such file or directory
DEBUG: pk_recv: retry[0] recv()
DEBUG: got pfkey ADD message

and this appears to be the only smoking gun from racoon output.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Degroote]

Post by Darren Reed

Post by John Nemeth
} > }
} > } 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.
}
} 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.
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;

Post by John Nemeth
Also, just encrypting icmp is next to useless.

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

Post by John Nemeth
} 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.

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

[Robert Elz]

Date: Mon, 11 Nov 2013 13:18:25 +0100
From: Arnaud Degroote <***@laas.fr>
Message-ID: <***@bugfree>

| You should look closer at
[.....]

Thanks, that helps,

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

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

I don't know enough about IPsec, but it strikes me as plausible, at
least, that this is because they are currently established. Do new ssh
connections work, or do they fail too?

Or is it definitely supposed to work to reconfigure IPsec for
established connections without disrupting them?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Mon, 11 Nov 2013 07:19:11 +1100
From: Darren Reed <***@NetBSD.org>
Message-ID: <***@netbsd.org>

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

Just to be sure, and ask the obvious question, you are adding the spdadd
policies at both ends (with the obvious address changes etc) at the same
time, right?

| To be more precise, I don't want ssh packets to be handled
| by IPsec because (a) there's no need to encrypt encrypted
| data

Until you get it working, I think I'd ignore this, and your other
reason, and just make ssh work over ipsec to show that it can be done
the same as any other tcp client application. Once you have overcome
whatever problem appears to be preventing that working, then I'd start
looking at avoiding ipsec for ssh (which unless hiding the fact that you're
using ssh is an objective, does look like it would be overkill.)

| this is the policy that I want to deploy
| and it seems like it should be possible. Question is,
| why can't I?

The real reason reason I'm here, is that it seems that ipsec knowledgable
people are (probably) reading this thread, and I have long had a similar
(but even more specific) ipsec application in mind, which I also have no
idea at all how to achieve, but which, at least to me, seems like it should
be possible (for ipsec as it is specified, whether or not it is as
implemented).

That is, I'd like to be able to enable ipsec on a single already established
tcp (or udp) connection (for udp, imagine as much an equivalent of a
connection as makes sense for this) (that is, on the IP packets that
support the connection, and not (by virtue of this request) on any others
between the same, or different, peers.

For the purposes of this question, you can assume that there are no issues
with either synchronisation of the enabling of ipsec, nor of keying.
(For the actual application I have in mind, that's true, but it is too
convoluted to bother explaining here.) For the purpose of this message,
assume that the applications simply know to enable ipsec immediately after
the TCP 3 way handshake has completed, or after the first (one) packet
is sent/received (before the first reply) for UDP, and that the key is N bits
of all 0's (where N is whatever is appropriate for whichever encryption
algorithm is selected, which the applications will simply know in advance).
That is, you can assume for this that what I really want is neither secrecy
nor authentication, but just a much stronger checksum algorithm than TCP
offers, and by using IPsec with a constant key, that's more or less what
I get (silly idea, but not absurd, if we assume that the application protocol
cannot be altered in any way, and that it simply assumes that TCP (or UDP)
is good enough - but I want better data accuracy that that.

So, given I have a connected (TCP or UDP) socket, what ioctl's do I need
to emit to get ipsec enabled on exactly this one connection (obviously
I know the port numbers and addresses of both ends, and which protocol I
am using ...) ?

For this purpose, I obviously want to do it directly from the application,
not go fiddling with ipsec configuration files, setkey commands, or anything
like that.

That is, if this is possible at all? Everything I've seen in the ipsec
documentation seems to assume that I want to use it for a VPN style use,
where (almost) all communications between two end points are to be protected.
There is however, nothing I can see in the base design of ipsec that
requires that model (allows it, certainly, but not requires.)

Any hints?

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Degroote]

Post by Robert Elz
Date: Mon, 11 Nov 2013 07:19:11 +1100
The real reason reason I'm here, is that it seems that ipsec knowledgable
people are (probably) reading this thread, and I have long had a similar
(but even more specific) ipsec application in mind, which I also have no
idea at all how to achieve, but which, at least to me, seems like it should
be possible (for ipsec as it is specified, whether or not it is as
implemented).
That is, I'd like to be able to enable ipsec on a single already established
tcp (or udp) connection (for udp, imagine as much an equivalent of a
connection as makes sense for this) (that is, on the IP packets that
support the connection, and not (by virtue of this request) on any others
between the same, or different, peers.
For the purposes of this question, you can assume that there are no issues
with either synchronisation of the enabling of ipsec, nor of keying.
(For the actual application I have in mind, that's true, but it is too
convoluted to bother explaining here.) For the purpose of this message,
assume that the applications simply know to enable ipsec immediately after
the TCP 3 way handshake has completed, or after the first (one) packet
is sent/received (before the first reply) for UDP, and that the key is N bits
of all 0's (where N is whatever is appropriate for whichever encryption
algorithm is selected, which the applications will simply know in advance).
That is, you can assume for this that what I really want is neither secrecy
nor authentication, but just a much stronger checksum algorithm than TCP
offers, and by using IPsec with a constant key, that's more or less what
I get (silly idea, but not absurd, if we assume that the application protocol
cannot be altered in any way, and that it simply assumes that TCP (or UDP)
is good enough - but I want better data accuracy that that.
So, given I have a connected (TCP or UDP) socket, what ioctl's do I need
to emit to get ipsec enabled on exactly this one connection (obviously
I know the port numbers and addresses of both ends, and which protocol I
am using ...) ?
For this purpose, I obviously want to do it directly from the application,
not go fiddling with ipsec configuration files, setkey commands, or anything
like that.
That is, if this is possible at all? Everything I've seen in the ipsec
documentation seems to assume that I want to use it for a VPN style use,
where (almost) all communications between two end points are to be protected.
There is however, nothing I can see in the base design of ipsec that
requires that model (allows it, certainly, but not requires.)

VPN is probably the 'classic usage' of IPSEC, through it is completely
possible to protect only specific port for specific IP, as shown by
Darren.

If you want to use a programming interface instead of setkey, you can
use the function ipsec_set_policy (3) from libipsec which takes the same
kind of input than setkey (8). Some low-level API exists, but are not
documented. Dig into libpfkey.h. The protocol used if PFKEY, as
described in RFC 2367.

Hope it helps.

[Robert Elz]

Date: Mon, 11 Nov 2013 11:49:14 +0100
From: Arnaud Degroote <***@NetBSD.org>
Message-ID: <***@bugfree>


| If you want to use a programming interface instead of setkey, you can
| use the function ipsec_set_policy (3) from libipsec which takes the same
| kind of input than setkey (8).

Thanks, that does help a little - but that interface just seems to take
a textual description of the policy (which I don't have, but could produce
with a little sprintf'ing - though doing so seems a little perverse),
and converts it into a binary structure (that I could probably just fill
in with C assignment statements - the values for it should not be hard to find,
and don't in any way depend upon any external specification - just what
port numbers happen to have been assigned to my socket when it connected)

But, that doesn't tell me what to do with the structure when I have built
it, and I think that's really what I wanted to know.

| Some low-level API exists, but are not documented.

That's what I was afraid of. And I think it is that that I really need
to get access to.

| Dig into libpfkey.h.

Thanks, but ... that shows me the structure used, which contains many
fields whose purpose is way beyond anything I can even guess at, and
prototypes for lots of functions whose purpose I have no idea of (I
have just taken a quick glance so far, but there look to be too many
for pure trial and error to ever come up with anything useful.)

| The protocol used if PFKEY, as described in RFC 2367.

That probably helps more, thanks - do we believe that NetBSD supports
the interface in that RFC completely?

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Degroote]

Post by Robert Elz
Date: Mon, 11 Nov 2013 11:49:14 +0100
| If you want to use a programming interface instead of setkey, you can
| use the function ipsec_set_policy (3) from libipsec which takes the same
| kind of input than setkey (8).
Thanks, that does help a little - but that interface just seems to take
a textual description of the policy (which I don't have, but could produce
with a little sprintf'ing - though doing so seems a little perverse),
and converts it into a binary structure (that I could probably just fill
in with C assignment statements - the values for it should not be hard to find,
and don't in any way depend upon any external specification - just what
port numbers happen to have been assigned to my socket when it connected)
But, that doesn't tell me what to do with the structure when I have built
it, and I think that's really what I wanted to know.
| Some low-level API exists, but are not documented.
That's what I was afraid of. And I think it is that that I really need
to get access to.
| Dig into libpfkey.h.
Thanks, but ... that shows me the structure used, which contains many
fields whose purpose is way beyond anything I can even guess at, and
prototypes for lots of functions whose purpose I have no idea of (I
have just taken a quick glance so far, but there look to be too many
for pure trial and error to ever come up with anything useful.)
| The protocol used if PFKEY, as described in RFC 2367.
That probably helps more, thanks - do we believe that NetBSD supports
the interface in that RFC completely?

I would say YES + some extensions. Through, it is not a 100% guarantee.

You should look closer at

pfkey_send_add2 (add SA)
pfkey_send_update2 (update SA)
pkfey_send_delete (delete SA)

and

pfkey_send_spd{add,update,delete} (add,update,delete SP)

The code, in correlation with the RFC, is relatively simple to
understand.
Or you can use directly pfkey_{send, recv} which use directly sadb_msg
(in net/pfkeyv2.h)

[Thor Lancelot Simon]

Post by Darren Reed
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.

That strikes me as extremely odd. Have you tested with any other
TCP based protocol?

For the record, we run SSH over both ESP and AH on TNF's own
servers all the time, and have done so both statically and
dynamically keyed, and it works fine.

Are you also using ipfilter? Is it perhaps the case that your
ipfilter rules are -- somehow -- blocking some of the ESP packets
carrying the SSH traffic?

It is not too hard to require ESP for traffic to/from a particular
TCP port with the KAME policy engine in NetBSD. It is quite hard
to create an "everything but X" exception. One way to do so is
to use transport mode IPsec with a gif interface to get a second,
post-decryption, filter point for the traffic, and use a combination
of IPsec policy and packet filter rules to implement the exception.

This does not play nicely with dynamic keying, however, because
racoon does not know how to deal with the gif interface.

In any case, if your SSH traffic stops flowing when it is encapsulated
in ESP, something is seriously broken; I would proceed no further
without debugging it, certainly not into something as complex as
excluding some traffic from IPsec but not other traffic.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Darren Reed
The man page for setkey seems to suggest that there is a priority
mechanism that would allow me to create a "none" SPD for ssh
packets but setkey on NetBSD doesn't support this. If I understand
spdadd A.B.C.D/32 E.F.G.0/24 any -P in priority low ipsec
esp/tunnel/A.B.C.D-E.F.G.H/require;
spdadd E.F.G.0/24 A.B.C.D/32 any -P out priority low ipsec
esp/tunnel/E.F.G.H-A.B.C.D/require;
spdadd A.B.C.D/32[22] E.F.G.0/24[any] tcp -P in priority high none;
spdadd E.F.G.0/24[any] A.B.C.D/32[22] tcp -P out priority high none;

I have only skimmed this rather huge (and surprisingly contentious)
thread.

Two points about your policies:

They have to match on both ends, inversely.

I believe it's first match, not last match. I am unaware of NetBSD
supporting priority on policies, and I haven't read the recent specs,
but I wasn't aware of that being in the RFCs (although it's arguably a
local matter).

To debug this, besides tcpdump, use netstat -p before and after trying,
to see which counters are going up.

So basically, put the ssh rules first, and then the generic rules.


It's still mysterious why ssh owuld fail with a working tunnel. (That
you want ssh excluded so you can use it to fix the other side of tunnels
is understandable.)

[Darren Reed]

Post by Greg Troxel

Post by Darren Reed
The man page for setkey seems to suggest that there is a priority
mechanism that would allow me to create a "none" SPD for ssh
packets but setkey on NetBSD doesn't support this. If I understand
spdadd A.B.C.D/32 E.F.G.0/24 any -P in priority low ipsec
esp/tunnel/A.B.C.D-E.F.G.H/require;
spdadd E.F.G.0/24 A.B.C.D/32 any -P out priority low ipsec
esp/tunnel/E.F.G.H-A.B.C.D/require;
spdadd A.B.C.D/32[22] E.F.G.0/24[any] tcp -P in priority high none;
spdadd E.F.G.0/24[any] A.B.C.D/32[22] tcp -P out priority high none;

I have only skimmed this rather huge (and surprisingly contentious)
thread.
They have to match on both ends, inversely.

When NAT is involved and NetBSD is behind the NAT device, how can they?

Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Darren Reed

Post by Greg Troxel
They have to match on both ends, inversely.

When NAT is involved and NetBSD is behind the NAT device, how can they?

I meant that the inbound policy on one system has to match the same
packets that the outbound policy on the other system matches. So if you
are using wildcard on address and just destination ports on machines
with global addresses, that should be ok.

[Darren Reed]

Maybe I'm approaching the solution wrong or maybe not..

My goal is to get two NetBSD hosts, each behind a NAT gateway
to talk to each other using IPsec using NAT-T.

This should work, shouldn't it?

Darren

From gateway 1, ipsec.conf:

spdadd 10.0.0.254/32 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254-64.33.101.23/require;
spdadd 10.1.2.0/24 10.0.0.254/32 icmp
-P in ipsec esp/tunnel/64.33.101.23-10.0.0.254/require;

spdadd 64.33.101.23/32 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/64.33.101.23-10.0.0.254/require;
spdadd 10.1.1.0/24 64.33.101.23/32 icmp
-P out ipsec esp/tunnel/10.0.0.254-64.33.101.23/require;

spdadd 10.1.2.0/24 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/64.33.101.23[4500]-10.0.0.254[4500]/require;
spdadd 10.1.1.0/24 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254[4500]-64.33.101.23[4500]/require;

and racoon.conf:

path pre_shared_key "/etc/ipsec-key.txt";

listen {
isakmp_natt 10.0.0.254 [4500];
isakmp 10.0.0.254 [500];
strict_address;
}

remote anonymous
{
exchange_mode main;
lifetime time 24 hour;
my_identifier address 10.0.0.254;
peers_identifier address 64.33.101.23;
ike_frag on;
esp_frag 1440;
initial_contact on;
proposal_check claim;
support_proxy on;
nat_traversal force;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp2048;
lifetime time 30 hours;
dh_group 2;
}
proposal_check obey;
}

sainfo anonymous
{
pfs_group 2;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

log debug;

mode_cfg {
auth_source system;
conf_source local;
accounting none;
}

From gateway 2, ipsec.conf:
spdadd 10.0.0.254/32 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254-177.3.11.43/require;
spdadd 10.1.2.0/24 10.0.0.254/32 icmp
-P in ipsec esp/tunnel/177.3.11.43-10.0.0.254/require;

spdadd 177.3.11.43/32 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/177.3.11.43-10.0.0.254/require;
spdadd 10.1.1.0/24 177.3.11.43/32 icmp
-P out ipsec esp/tunnel/10.0.0.254-177.3.11.43/require;

spdadd 10.1.2.0/24 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/177.3.11.43[4500]-10.0.0.254[4500]/require;
spdadd 10.1.1.0/24 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254[4500]-177.3.11.43[4500]/require;

and racoon.conf:
path pre_shared_key "/etc/ipsec-key.txt";

listen {
isakmp_natt 10.0.0.254 [4500];
isakmp 10.0.0.254 [500];
strict_address;
}

remote anonymous
{
exchange_mode main;
lifetime time 24 hour;
my_identifier address 10.0.0.254;
peers_identifier address 177.3.11.43;
ike_frag on;
esp_frag 1440;
initial_contact on;
proposal_check claim;
support_proxy on;
nat_traversal force;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp2048;
lifetime time 30 hours;
dh_group 2;
}
proposal_check obey;
}

sainfo anonymous
{
pfs_group 2;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

log debug;

mode_cfg {
auth_source system;
conf_source local;
accounting none;
}


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Post by Darren Reed
This should work, shouldn't it?
path pre_shared_key "/etc/ipsec-key.txt";

pre-shared indexed by IP addresses are really hard to make sense of through
NAT. Remember that each end is sending it's ID as it's private IP, but the
packets come from the public IP. Looks like a MITM attack, because it is.

Use RSA or use FQDNs to identify your machines, and your life will be much
easier (on ikev1, you'll have to use aggressive mode)

And, obviously, your NAT's need to have port 500/4500 plugged through on at
least one end.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Masaru OKI]

If NAT gateway has no port forwarding rule, initiate packet is
not reached to responder, I think.

Post by Darren Reed
Maybe I'm approaching the solution wrong or maybe not..
My goal is to get two NetBSD hosts, each behind a NAT gateway
to talk to each other using IPsec using NAT-T.
This should work, shouldn't it?
Darren
spdadd 10.0.0.254/32 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254-64.33.101.23/require;
spdadd 10.1.2.0/24 10.0.0.254/32 icmp
-P in ipsec esp/tunnel/64.33.101.23-10.0.0.254/require;
spdadd 64.33.101.23/32 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/64.33.101.23-10.0.0.254/require;
spdadd 10.1.1.0/24 64.33.101.23/32 icmp
-P out ipsec esp/tunnel/10.0.0.254-64.33.101.23/require;
spdadd 10.1.2.0/24 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/64.33.101.23[4500]-10.0.0.254[4500]/require;
spdadd 10.1.1.0/24 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254[4500]-64.33.101.23[4500]/require;
path pre_shared_key "/etc/ipsec-key.txt";
listen {
isakmp_natt 10.0.0.254 [4500];
isakmp 10.0.0.254 [500];
strict_address;
}
remote anonymous
{
exchange_mode main;
lifetime time 24 hour;
my_identifier address 10.0.0.254;
peers_identifier address 64.33.101.23;
ike_frag on;
esp_frag 1440;
initial_contact on;
proposal_check claim;
support_proxy on;
nat_traversal force;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp2048;
lifetime time 30 hours;
dh_group 2;
}
proposal_check obey;
}
sainfo anonymous
{
pfs_group 2;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
log debug;
mode_cfg {
auth_source system;
conf_source local;
accounting none;
}
spdadd 10.0.0.254/32 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254-177.3.11.43/require;
spdadd 10.1.2.0/24 10.0.0.254/32 icmp
-P in ipsec esp/tunnel/177.3.11.43-10.0.0.254/require;
spdadd 177.3.11.43/32 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/177.3.11.43-10.0.0.254/require;
spdadd 10.1.1.0/24 177.3.11.43/32 icmp
-P out ipsec esp/tunnel/10.0.0.254-177.3.11.43/require;
spdadd 10.1.2.0/24 10.1.1.0/24 icmp
-P in ipsec esp/tunnel/177.3.11.43[4500]-10.0.0.254[4500]/require;
spdadd 10.1.1.0/24 10.1.2.0/24 icmp
-P out ipsec esp/tunnel/10.0.0.254[4500]-177.3.11.43[4500]/require;
path pre_shared_key "/etc/ipsec-key.txt";
listen {
isakmp_natt 10.0.0.254 [4500];
isakmp 10.0.0.254 [500];
strict_address;
}
remote anonymous
{
exchange_mode main;
lifetime time 24 hour;
my_identifier address 10.0.0.254;
peers_identifier address 177.3.11.43;
ike_frag on;
esp_frag 1440;
initial_contact on;
proposal_check claim;
support_proxy on;
nat_traversal force;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp2048;
lifetime time 30 hours;
dh_group 2;
}
proposal_check obey;
}
sainfo anonymous
{
pfs_group 2;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
log debug;
mode_cfg {
auth_source system;
conf_source local;
accounting none;
}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Michael Richardson

Post by Darren Reed
This should work, shouldn't it?
path pre_shared_key "/etc/ipsec-key.txt";

pre-shared indexed by IP addresses are really hard to make sense of through
NAT. Remember that each end is sending it's ID as it's private IP, but the
packets come from the public IP. Looks like a MITM attack, because it is.
Use RSA or use FQDNs to identify your machines, and your life will be much
easier (on ikev1, you'll have to use aggressive mode)

Ok, so I've found this page that talks about RSA:
http://gradew.net/?page_id=212&lang=en

... but the problem here is that it is one sided: one end is the server and
the other is the client. I want to do symmetrical configuration where both
ends are peers and either end can bring up the tunnel.

I'll try FQDN...

Post by Michael Richardson
And, obviously, your NAT's need to have port 500/4500 plugged through on at
least one end.

That has been taken care of.

Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de