[Openswan Users] UDP 500 Bounces

[Jerome Kaidor]

Hello,

   I'm trying to get IPSEC working between my linux box and a Win XP  machine,
and not making much headway.  Tcpdump shows that the very first step of 
ISAKMP negotiations is failing.  My Windows laptop sends a "phase 1 I ident"
to the linux box, and the linux box replies with an icmp 312: udp port isakmp
unreachable.

   Now, my first inclination was to check my IPTABLES firewall script where
I had explicitly enabled udp 500 for ingress and egress at the external
interface of the Linux box.  I ran my "loose firewall" script, which opens
up EVERYTHING - no difference.

   So I guess that leaves pluto:  ps ax | grep pluto:

 2645 ?        Ss     0:00 /usr/local/libexec/ipsec/pluto
 2646 ?        SN     0:00 pluto helper  #  0
 2647 ?        S      0:00 _pluto_adns

 ...yup, it seems to be running.  But somehow, UDP 500 packets are being
rejected.  Anybody have a clue as to how to troubleshoot this?
Maybe a place in /proc or whatever that shows what UDP ports are bound to 
what applications?

  I note that there's no mention of pluto in /etc/inetd.conf....

The system in question is a Linux 2.4.31 kernel, and openswan-2.3.1,
compiled from source.  The system was originally a Slackware 10.0.
The kernel has KLIPS and nat-t installed from the openswan.  The output from
"ipsec verify" looks reasonably sane:

----------------------- snip --------------------------------
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.3.1/Kcvs2002Mar11_16:19:03 (klips)
Checking for IPsec support in kernel                            [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]

Opportunistic Encryption DNS checks:
   Looking for TXT in forward dns zone: tr4                     [MISSING]
   Does the machine have at least one non-private address?      [OK]
   Looking for TXT in reverse dns zone: 85.114.193.63.in-addr.arpa.     [MISSING]
--------------------- endsnip -------------------------------------

Ipsec whack --status also looks like good stuff, although I'm not familiar
with the details:

----------------------- snip ---------------------------------
000 %myid = (none)
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=168, keysizemax=168
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000
000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0}
attrs={0,0,0}
000
000
000
----------------------- endsnip ------------------------------

So: Anybody seen this before?  Troubleshooting hints?  Thanks in advance,


                  - Jerry Kaidor ( jerry at tr2.com )