Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ipsec transport-mode between win2k and freebsd

2 views
Skip to first unread message

Markus Muessig

unread,
Jul 1, 2003, 9:17:17 AM7/1/03
to
Hello forum,
i came in trouble with the following configuration:

os
win2k ---------------------- freebsd ---------------------- local lan

ip
192.168.1.2 ------- 192.168.1.1 --- 192.168.0.69 ----- 192.168.0.0/24


on freebsd i use the following racoon.conf:

path include "/usr/local/etc/racoon" ;
path certificate "/etc/vpn/certs" ;
log notify;
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}
listen
{
isakmp 192.168.1.1 [500];
}

timer
{
counter 5;
interval 20 sec;
persend 1;
phase1 300 sec;
phase2 15 sec;
}

remote anonymous
{
my_identifier asn1dn;
peers_identifier asn1dn;
certificate_type x509 "gw.testdomain.de.crt" "gw.testdomain.de.key";
generate_policy on;
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;
nonce_size 16;
lifetime time 3600 sec;
initial_contact off;
support_mip6 on;
proposal_check obey;
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method rsasig;
dh_group 2;
}
}

sainfo anonymous
{
pfs_group 1;
lifetime time 36000 sec;
encryption_algorithm 3des ;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}


this is my ipsec.conf script for initiating sp's:

#!/usr/local/bin/bash
setkey -FP
setkey -F
setkey -c cat << EOF
spdadd 0.0.0.0 192.168.0.0/24 any -P out ipsec esp/transport//use;
spdadd 192.168.0.0/24 0.0.0.0 any -P in ipsec esp/transport//use;
EOF

the 0.0.0.0 stands for any address (i hope this will work)!

if i ping now from the windows client to an ip-address in the
protected net (192.168.0.0/24) i get an:

ip-security negotiation (my translation of what i get on a german
win2k)

and on the gateway i can tcpdump packets from 192.168.1.2:500 to
192.168.0.254:500 !

my problem is the transport mode! ping packets form win2k are not sent
to my security-gateway, but direct to the destination-address of
the ping to port 500!

of course, there is no remote end configuration like if i configure
a tunnel mode (on windows you have to specify a remote and a local end
of the tunnel which obviously defines where to negotiate sa's). But
in transport mode?
Where to define who your security-gateway is?
sounds very basically question, but i allways did
tunnel-mode-ipsecs...
and tunnel does not work with dynamic roadwarrior ips like roaming
win2k...

any help/ideas?

greetings, markus muessig
--
-----------------------------------------------------------------------------
UNIX IS NOT UNFRIENDLY, IT'S JUST PICKY ABOUT ITS FRIENDS

Markus Muessig

unread,
Jul 2, 2003, 3:44:21 AM7/2/03
to
Hello forum,
up to now, i am in really (reasonable) doubt about the suitability of
transport mode to connect a roadwarrior and a router for secure traffic
between roadwarrior and the net behind the router over internet!
for there is no tunnel in configuration for transport mode, policy's
destination-address and src (which is normally "own ip address") decides
which packets from roadwarrior to destination (which can be the router, or
the network behind) is encrypted.
this "problem" ends up in attempting to negotiate isakmp-sa with the address
i try to connect (via ping, via http...)! So, of course the imaginary
fileserver in my remote lan has no clue from what to do with packets coming
to port 500. but actually that is what happens.

1.
if i define a remote ip-address in my win2k's ipsec policy as a destination
address for outgoing packets, exactly packtes to that ip-address are
secured. so it is not suitable for my purpose.

2.
if i define a remote (private) network in my win2k'2 ipsec policy as a
destination address for outgoing packets, no policy could be negotiated,
inspite i defined every possible direction and src/dst-combination on
gateway (via setkey...). this is clear, cause the machine from which i want
to use resources does not run an ipsec-implementation.

conclusion:
if you want to connect to a entire network, transport mode is not practical
at all, except you implement a ipsec/isakmp software on every machine you
want use resources from?! is that right?
tunnelmode is the only possibility to use resources from a entire network.
only the remote security gateway has to know ipsec/isakmp packets arriving
on port 500?!

please comment/complete/correct my statements or help me to find an
alternative way (not less secure and easy to use as ipsec) to connect a
single roaming win2k client to a entire network behind a nat'ing router.

greetings, and thanks, markus muessig

0 new messages