login
Login / Register
Header Space

 
 

Home » Mailing list archives » openbsd-misc » 2007 » April » 23

Re: Problems with second ipsec(ctl) tunnel

Previous thread: anyone using zoneminder.com on OpenBSD? by Paul Pruett on Monday, April 23, 2007 - 10:18 am. (6 messages)

Next thread: radeon driver in -current Xorg 7.2? by Sunnz on Monday, April 23, 2007 - 1:23 pm. (17 messages)
[view original message]
From: Steven Surdock <ssurdock@...>
To: <misc@...>
Subject: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 12:42 pm

Greetings, I recently converted from isakmpd.conf to ipsec.conf and I
seem to be having problem bringing up a second tunnel to a PIX.  It
_appears_ that the OBSD side is trying to use the default hmac
(sha2_256) even though it is configured to use md5 for the second
tunnel.  Oddly, the first tunnel comes up fine.  Any insight or
trouble-shooting tips would be appreciated.  BTW, Is there anyway to see
what flows have been "configured"?  "ipsecctl -sf" seemed to only show a
flow when phase I was complete.

ipsecctl -sf
--------
flow esp in from 192.168.60.192/28 to 10.10.0.0/16 peer 192.168.40.8
srcid 192.168.13.4/32 dstid 192.168.40.8 type use
flow esp out from 10.10.0.0/16 to 192.168.60.192/28 peer 192.168.40.8
srcid 192.168.13.4/32 dstid 192.168.40.8 type require
++++++++
The local peer (OpenBSD 4.0-stable (GENERIC) #6: Fri Apr 13 07:23:48 EDT
2007) is configured like:
--------
ike esp from { 10.10.0.0/16 , 10.5.0.0/24 } to 192.168.60.192/28 \
        peer  192.168.40.8 \
        local 192.168.13.4 \
        main auth hmac-md5 enc aes group modp1024 \
        psk "Hereismylovelykey"
++++++++
/var/log/messages:
--------
Apr 23 12:28:52 fw1 isakmpd[965]: transport_send_messages: giving up on
exchange IPsec-10.5.0.0/24-192.168.60.192/28, no response from peer
192.168.40.8:500
Apr 23 12:28:52 fw1 isakmpd[965]: message_recv: bad message length
Apr 23 12:28:52 fw1 isakmpd[965]: dropped message from 192.168.40.8 port
500 due to notification type &lt;Unknown 0&gt;
...more of the above
Apr 23 12:29:37 fw1 isakmpd[965]: dropped message from 192.168.40.8 port
500 due to notification type &lt;Unknown 0&gt;
Apr 23 12:30:25 fw1 isakmpd[965]: message_validate_notify: protocol not
supported
Apr 23 12:30:33 fw1 isakmpd[965]: message_recv: bad message length
++++++++
The remote is a PIX configured like:
--------
access-list 100 permit ip 192.168.60.192 255.255.255.240 10.10.0.0
255.255.0.0
access-list 100 permit ip 192.168.60.192 255.255.255.240 10.5.0.0
255.255.255.0
sysopt connectio...
[ message continues ]
[view original message]
From: Steven Surdock <ssurdock@...>
To: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Tuesday, April 24, 2007 - 3:49 pm

No answers?  Rats!  Can anyone confirm that they have multiple tunnels
using ipsec.conf to a non-OBSD box with non-OBSD-default IPSec
auth/encryption?  Otherwise I guess I'll have to experiment more...
Thanks!

-Steve S.
[view original message]
From: Stuart Henderson <stu@...>
To: Steven Surdock <ssurdock@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Tuesday, April 24, 2007 - 4:05 pm

Are auth/encryption the same for both tunnels? I believe that may
be necessary for main mode.

You can check that ipsec.conf is being parsed how you expect with
'ipsecctl -nvf /etc/ipsec.conf' (it will output the generated
isakmpd.conf-style sections which are fed to isakmpd's fifo);
this may give some clues.
[view original message]
From: Steven Surdock <ssurdock@...>
To: Stuart Henderson <stu@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Tuesday, April 24, 2007 - 9:48 pm

And it did.  Thanks!  I again checked against the configured transforms
and indeed I had a mismatch.  What confused me was that the first tunnel
came up - apparently with a mismatch in transform.  Thanks again!
[view original message]
From: Prabhu Gurumurthy <pgurumu@...>
To: Steven Surdock <ssurdock@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 1:06 pm

I too have the same problem.
I have a Lan 2 Lan tunnel with pfsync, carp, sasync and it works flawlessly with 
another OpenBSD system as the peer.

I tried to enable OpenBSD to PIX tunnel (PIX 501, OS: 6.3(5))

I defined "quick auth hmac-sha enc aes", when I do that I get phase 1 completed.

ipsec.conf
ike esp from 172.30.75.0/24 to 192.168.137.0/24 \
         local 10.200.3.7 peer 10.200.3.1 \
         main auth hmac-sha1 enc aes \
         quick auth hmac-sha enc aes \
         srcid 10.200.3.7 psk "F00F00Bar"

snippet from PIX firewall:

crypto ipsec transform-set IPSEC_SET esp-aes-256 esp-sha-hmac
crypto map VPN_MAP 1 ipsec-isakmp
crypto map VPN_MAP 1 match address VPN_ACL
crypto map VPN_MAP 1 set peer 10.200.3.7
crypto map VPN_MAP 1 set transform-set IPSEC_SET
crypto map VPN_MAP interface outside
isakmp enable outside
isakmp key ******** address 10.200.3.7 netmask 255.255.255.255 no-xauth
isakmp identity address
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption aes-256
isakmp policy 1 hash sha
isakmp policy 1 group 2
isakmp policy 1 lifetime 1800

pixfirewall# sh crypto isakmp sa
Total     : 1
Embryonic : 0
         dst               src        state     pending     created
       10.200.3.1       10.200.3.7    QM_IDLE         0           0

But phase 2 does not established at all for some reason!

Does anybody need any more logs?

Thanks
Prabhu
-
[view original message]
From: Steven Surdock <ssurdock@...>
To: <pgurumu@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 1:16 pm

...
I don't think "hmac-sha" is a valid argument for your Phase II.

-Steve S.
[view original message]
From: Prabhu Gurumurthy <pgurumu@...>
To: Steven Surdock <ssurdock@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 1:24 pm

Yes, thanks but that was a typo.. sorry for the confusion, still the tunnel does 
not come up.

Thanks
Prabhu
-
[view original message]
From: Steven Surdock <ssurdock@...>
To: <pgurumu@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 1:29 pm

What does your ACL "VPN_ACL" look like?  How about the output from a
"debug crypto isakmp" from the PIX?

-Steve S.
[view original message]
From: Prabhu Gurumurthy <pgurumu@...>
To: Steven Surdock <ssurdock@...>
Cc: <misc@...>
Subject: Re: Problems with second ipsec(ctl) tunnel
Date: Monday, April 23, 2007 - 2:38 pm

Ah.. finally figured it out!

Mismatch on encryption:

On PIX side I had:

crypto ipsec transform-set IPSEC_SET esp-aes-256 esp-sha-hmac

On OpenBSD side I had:

ike esp from 172.30.75.0/24 to 192.168.137.0/24 \
         local 10.200.3.7 peer 10.200.3.1 \
         main auth hmac-sha1 enc aes \
         quick auth hmac-sha1 enc aes \
         srcid 10.200.3.7 psk "!PS3c1nf0"


When I enabled debug crypto ipsec and debug crypto isakmp:

crypto_isakmp_process_block:src:10.200.3.7, dest:10.200.3.1 spt:53766 dpt:500
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0

ISAKMP (0): Checking ISAKMP transform 0 against priority 1 policyp
ISAKMP:      encryption AES-CBC
ISAKMP:      hash SHA
ISAKMP:      auth pre-share
ISAKMP:      default group 2
ISAKMP:      life type in seconds
ISAKMP:      life duration (basic) of 3600
ISAKMP:      keylength of 256
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): processing vendor id payload

ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T
ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T
ISAKMP (0): processing vendor id payload

ISAKMP (0): processing vendor id payload

ISAKMP (0): remote peer supports dead peer detection

ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
return status is IKMP_NO_ERROR
crypto_isakmp_process_block:src:10.200.3.7, dest:10.200.3.1 spt:53766 dpt:500
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0

ISAKMP (0): processing NONCE payload. message ID = 0

return status is IKMP_NO_ERROR
crypto_isakmp_process_block:src:10.200.3.7, dest:10.200.3.1 spt:53766 dpt:500
OAK_MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): SA has been authenticated

ISAKMP (0): ID payload
         next-payload : 8
         type         : 1
         protocol     : 17
         port         : 500
         length       :...
[ message continues ]
Previous thread: anyone using zoneminder.com on OpenBSD? by Paul Pruett on Monday, April 23, 2007 - 10:18 am. (6 messages)

Next thread: radeon driver in -current Xorg 7.2? by Sunnz on Monday, April 23, 2007 - 1:23 pm. (17 messages)

Mail archive search
Enter your search terms.
Optionally limit your search to a specific mailing list.
advanced
Recent Tags
more tags
Colocation donated by:
Who's online
There are currently 5 users and 1266 guests online.

Online users

Syndicate
Syndicate content
© 2007 KernelTrap.  |  Powered by Drupal.  |  Legal statement.
speck-geostationary