Hi,
[ still appropriate for tech@ ? ]
[ Cc: list clipped - we are all on tech@, anyway, aren't we? ]
On Tue, 13.04.2010 at 11:10:00 +0100, Stuart Henderson <s...@spacehopper.org>
wrote:
> flow esp in from 0.0.0.0/0 to somenetwork/24 type bypass
> flow esp out from somenetwork/24 to 0.0.0.0/0 type bypass
> flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
> dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type require
you intended that to be an ipsec.conf setup? Then I should emphasize
that 87.186.99.179 is a dynamically assigned IP number...
> the kernel also accepts requests to delete important system files,
> change routing table entries, shutdown the machine...
Ok, this sounds very much plausible. On towards isakmpd, then...
> It's the phase 2 setup that you're concerned about here, and that uses
> IPv4 IDs so you should be able to do this.. However isakmpd.policy *is*
> complicated and hard to get right and the current ipsecctl interface
> to isakmpd only deals with flows and not keynote policy.
I should reiterate (unless I missed to point it out in the first place)
that my configuration, the offending part of it being included below,
was running fine for several years and only broke down with the advent
of a new client software package.
Also, I'm confident that I'm not using IPv4 numbers as IDs. See this,
replicated from the test server that I set up:
Authorizer: "mobile-certs"
Comment: need to list all certificates for mobile users in the licensees section
Licensees: "DN:/Cert/Of/User1" ||
"DN:/Cert/Of/User2"
Conditions: app_domain == "IPsec policy"
&& esp_present == "yes"
&& esp_enc_alg == "aes"
&& phase_1 == "main"
&& phase1_group_desc == "5"
&& esp_encapsulation == "tunnel"
&& esp_auth_alg == "hmac-sha"
&& ( esp_key_length == "256" || esp_key_length == "128" )
&& remote_filter_type == "IPv4 address"
&& remote_filter == "192.168.003.000-192.168.003.255"
&& remote_filter_addr_lower == "192.168.003.000"
&& remote_filter_addr_upper == "192.168.003.255"
&& pfs == "yes"
&& remote_id_type == "User FQDN"
&& ( remote_id == "us...@example.com" || remote_id ==
"us...@example.com" ) -> "true";
The logs show very interesting things here: For the working correction,
isakmpd logs this:
...
@400000004bc4583501a93d54 134027.027819 Plcy 80 remote_filter_type == IPv4
address
@400000004bc4583501a94cf4 134027.027844 Plcy 80 remote_filter_addr_upper ==
192.168.003.151
@400000004bc4583501a958ac 134027.027849 Plcy 80 remote_filter_addr_lower ==
192.168.003.151
@400000004bc4583501aa1bfc 134027.027861 Plcy 80 remote_filter == 192.168.003.151
...
The IP address, 192.168.003.151, is assigned using IKECFG. Please note
that the filter statements don't reflect the configuration.
For the broken connection with that same client, as far as my
configuration is concerned, isakmpd logs this:
...
@400000004bc46e072af0745c 151333.720391 Plcy 80 remote_filter_type == IPv4
subnet
@400000004bc46e072af08fb4 151333.720394 Plcy 80 remote_filter_addr_upper ==
255.255.255.255
@400000004bc46e072af09b6c 151333.720398 Plcy 80 remote_filter_addr_lower ==
000.000.000.000
@400000004bc46e072af0a33c 151333.720402 Plcy 80 remote_filter ==
000.000.000.000-255.255.255.255
...
I'd say that one can at least conclude that the filter does not apply
because I can only specify one filter type, and suddenly, I'm looking
at a (broken) proposal of a different type.
I should also add that I'm still unable to use ipsec.conf, as I'm using
more features of IPSEC than I can express with ipsec.conf... so it's
old-style isakmpd.conf + isakmpd.policy over here. [OT: It would be
signed keynote credentials once I'd figure out the format.]
FWIW, the vendor of the package says that he only changed the Vendor-ID
between the two software versions, but in any case, it would now be time
to have _two_ (or more) different filters, instead of only one, which is
all I can see possible in isakmpd.policy(5).
--
Kind regards,
--Toni++
