From: Gabriel S. <gs...@gm...> - 2007-06-12 22:14:11
|
> racoon not ignoring some ACQUIRES > <200...@fa...> Apologies for being ignorant, but where could I download this patch ? I'm running latest cvs, trying to connect to an ASA5540 in remote-access client mode, and I'm now getting past the phase1 setup. I have racoon call the sample phase1_up/down scripts, which set up a bunch of stuff (routing, an extra subinterface for eth0, resolv.conf, etc). However, when I try to send traffic through the tunnel, racoon displays this: pk_recv: retry[0] recv() get pfkey ACQUIRE message ... some large hex blob ... ignore because do not listen on source address: 192.168.123.234 (that's my usual, "public" ip address on the machine I used). I run FC6 and latest cvs, and was wondering if this patch might have anything to do with my problem, before I actually start paying attention to the detailed debug log :) Thanks, Gabriel |
From: Joy L. <la...@au...> - 2007-06-13 14:32:16
|
On Tue, 2007-06-12 at 18:14 -0400, Gabriel Somlo wrote: > > racoon not ignoring some ACQUIRES > > <200...@fa...> > > > Apologies for being ignorant, but where could I download this patch ? > > I'm running latest cvs, trying to connect to an ASA5540 in remote-access > client mode, and I'm now getting past the phase1 setup. I have racoon > call the sample phase1_up/down scripts, which set up a bunch of stuff > (routing, an extra subinterface for eth0, resolv.conf, etc). > > However, when I try to send traffic through the tunnel, racoon displays this: > > pk_recv: retry[0] recv() > get pfkey ACQUIRE message > ... > some large hex blob > ... > ignore because do not listen on source address: 192.168.123.234 > > (that's my usual, "public" ip address on the machine I used). > > I run FC6 and latest cvs, and was wondering if this patch might have anything > to do with my problem, before I actually start paying attention to the detailed > debug log :) I am not sure this patch will fix the problem you are describing. It seems your racoon doesn't believe "192.168.123.234" is one of his source addresses to listen for. From what I can tell of code, racoon will only process ACQUIRES that have a source address that matches his list of source addresses. You mentioned a sub-interface for eth0, is it 192.168.123.234? Regards, Joy |
From: Gabriel S. <gs...@gm...> - 2007-06-13 23:40:25
|
On 6/13/07, Joy Latten <la...@au...> wrote: > > pk_recv: retry[0] recv() > > get pfkey ACQUIRE message > > ... > > some large hex blob > > ... > > ignore because do not listen on source address: 192.168.123.234 > > > > (that's my usual, "public" ip address on the machine I used). ... > You mentioned a sub-interface for eth0, is it 192.168.123.234? Before I connect to the VPN server, I have this: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:0b:db:7d:54:7d brd ff:ff:ff:ff:ff:ff inet 192.168.123.234/24 brd 192.168.123.255 scope global eth0 inet6 fe80::20b:dbff:fe7d:547d/64 scope link valid_lft forever preferred_lft forever After I connect, I get this: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:0b:db:7d:54:7d brd ff:ff:ff:ff:ff:ff inet 192.168.123.234/24 brd 192.168.123.255 scope global eth0 inet 172.31.4.4/16 brd 172.31.255.255 scope global eth0:1 inet6 fe80::20b:dbff:fe7d:547d/64 scope link valid_lft forever preferred_lft forever 172.31.4.4 is my vpn-server assigned client address, and shows up as eth0:1 in ifconfig. After looking at the racoon debug log once more, I noticed the following lines right after the phase1_up script was launched: 2007-06-13 16:42:42: ERROR: unsuitable address: eth0 172.31.4.4 2007-06-13 16:42:42: DEBUG: my interface: 192.168.123.234 (eth0) 2007-06-13 16:42:42: DEBUG: my interface: 127.0.0.1 (lo) 2007-06-13 16:42:42: DEBUG: configuring default isakmp port. 2007-06-13 16:42:42: DEBUG: 4 addrs are configured successfully 2007-06-13 16:42:42: ERROR: failed to bind to address 127.0.0.1[500] (Address already in use). 2007-06-13 16:42:42: ERROR: failed to bind to address 192.168.123.234[500] (Address already in use). 2007-06-13 16:42:42: ERROR: failed to bind to address ::1[500] (Address already in use). 2007-06-13 16:42:42: ERROR: failed to bind to address fe80::20b:dbff:fe7d:547d%eth0[500] (Address already in use). 2007-06-13 16:42:42: ERROR: no address could be bound. 2007-06-13 16:42:42: DEBUG: pk_recv: retry[0] recv() 2007-06-13 16:42:42: DEBUG: get pfkey REGISTER message However, the phase1_up script gets all the correct values, runs successfully, but anytime I try to send a packet through the tunnel to a new address, racoon gets an acquire and gives the error I was originally complaining about: 2007-06-13 16:43:37: DEBUG: pk_recv: retry[0] recv() 2007-06-13 16:43:37: DEBUG: get pfkey ACQUIRE message 2007-06-13 16:43:37: DEBUG: ignore because do not listen on source address : 192.168.123.234. Any clue as to what might happen is much appreciated ! Thanks, Gabriel |
From: Paul W. <Pau...@ta...> - 2007-06-14 07:17:13
|
What's in your racoon.conf? I had more luck (on linux) using interface dummy0 rather than eth0:1 as my private interface. Also what's in your routing table? What does "ip route show" display. Gabriel Somlo wrote: > On 6/13/07, Joy Latten <la...@au...> wrote: > >>>pk_recv: retry[0] recv() >>>get pfkey ACQUIRE message >>>... >>>some large hex blob >>>... >>>ignore because do not listen on source address: 192.168.123.234 >>> >>>(that's my usual, "public" ip address on the machine I used). > > ... > >>You mentioned a sub-interface for eth0, is it 192.168.123.234? > > > Before I connect to the VPN server, I have this: > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:0b:db:7d:54:7d brd ff:ff:ff:ff:ff:ff > inet 192.168.123.234/24 brd 192.168.123.255 scope global eth0 > inet6 fe80::20b:dbff:fe7d:547d/64 scope link > valid_lft forever preferred_lft forever > > After I connect, I get this: > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:0b:db:7d:54:7d brd ff:ff:ff:ff:ff:ff > inet 192.168.123.234/24 brd 192.168.123.255 scope global eth0 > inet 172.31.4.4/16 brd 172.31.255.255 scope global eth0:1 > inet6 fe80::20b:dbff:fe7d:547d/64 scope link > valid_lft forever preferred_lft forever > > 172.31.4.4 is my vpn-server assigned client address, and shows up as eth0:1 in > ifconfig. > > After looking at the racoon debug log once more, I noticed the > following lines right > after the phase1_up script was launched: > > 2007-06-13 16:42:42: ERROR: unsuitable address: eth0 172.31.4.4 > 2007-06-13 16:42:42: DEBUG: my interface: 192.168.123.234 (eth0) > 2007-06-13 16:42:42: DEBUG: my interface: 127.0.0.1 (lo) > 2007-06-13 16:42:42: DEBUG: configuring default isakmp port. > 2007-06-13 16:42:42: DEBUG: 4 addrs are configured successfully > 2007-06-13 16:42:42: ERROR: failed to bind to address 127.0.0.1[500] > (Address already in use). > 2007-06-13 16:42:42: ERROR: failed to bind to address > 192.168.123.234[500] (Address already in use). > 2007-06-13 16:42:42: ERROR: failed to bind to address ::1[500] > (Address already in use). > 2007-06-13 16:42:42: ERROR: failed to bind to address > fe80::20b:dbff:fe7d:547d%eth0[500] (Address already in use). > 2007-06-13 16:42:42: ERROR: no address could be bound. > 2007-06-13 16:42:42: DEBUG: pk_recv: retry[0] recv() > 2007-06-13 16:42:42: DEBUG: get pfkey REGISTER message > > However, the phase1_up script gets all the correct values, runs > successfully, but > anytime I try to send a packet through the tunnel to a new address, racoon gets > an acquire and gives the error I was originally complaining about: > > 2007-06-13 16:43:37: DEBUG: pk_recv: retry[0] recv() > 2007-06-13 16:43:37: DEBUG: get pfkey ACQUIRE message > 2007-06-13 16:43:37: DEBUG: ignore because do not listen on source > address : 192.168.123.234. > > > Any clue as to what might happen is much appreciated ! > > Thanks, > Gabriel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Gabriel S. <gs...@gm...> - 2007-06-14 12:12:46
|
On 6/14/07, Paul Winder <Pau...@ta...> wrote: > What's in your racoon.conf? path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; path script "/etc/racoon/scripts"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } remote 192.168.5.220 { exchange_mode main; my_identifier fqdn "foo.bar.com"; certificate_type x509 "test.crt" "test.key"; ca_type x509 "ca.crt"; mode_cfg on; script "p1_up_down" phase1_up; script "p1_up_down" phase1_down; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method xauth_rsa_client; dh_group 2; } } > Also what's in your routing table? What does "ip route show" display. Before 'racoonctl vc 192.168.5.220' it's this: 192.168.123.0/24 dev eth0 proto kernel scope link src 192.168.123.234 default via 192.168.123.1 dev eth0 Afterwards, it's this: 192.168.5.220 via 192.168.123.1 dev eth0 192.168.123.0/24 dev eth0 proto kernel scope link src 192.168.123.234 172.31.0.0/16 dev eth0 proto kernel scope link src 172.31.4.4 default via 192.168.123.1 dev eth0 src 172.31.4.4 Thanks much, Gabriel |
From: Paul W. <Pau...@ta...> - 2007-06-14 12:54:59
|
After phase1 do you get a message like: INFO: ISAKMP-SA established src-ip[port]-dest-ip[port] spi:... and what does setkey -PD show after phase 1? Paul Gabriel Somlo wrote: > On 6/14/07, Paul Winder <Pau...@ta...> wrote: > >> What's in your racoon.conf? > > > path include "/etc/racoon"; > path pre_shared_key "/etc/racoon/psk.txt"; > path certificate "/etc/racoon/certs"; > path script "/etc/racoon/scripts"; > > sainfo anonymous > { > pfs_group 2; > lifetime time 1 hour ; > encryption_algorithm 3des, blowfish 448, rijndael ; > authentication_algorithm hmac_sha1, hmac_md5 ; > compression_algorithm deflate ; > } > > remote 192.168.5.220 > { > exchange_mode main; > my_identifier fqdn "foo.bar.com"; > certificate_type x509 "test.crt" "test.key"; > ca_type x509 "ca.crt"; > mode_cfg on; > script "p1_up_down" phase1_up; > script "p1_up_down" phase1_down; > proposal > { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method xauth_rsa_client; > dh_group 2; > } > } > >> Also what's in your routing table? What does "ip route show" display. > > > Before 'racoonctl vc 192.168.5.220' it's this: > > 192.168.123.0/24 dev eth0 proto kernel scope link src 192.168.123.234 > default via 192.168.123.1 dev eth0 > > Afterwards, it's this: > > 192.168.5.220 via 192.168.123.1 dev eth0 > 192.168.123.0/24 dev eth0 proto kernel scope link src 192.168.123.234 > 172.31.0.0/16 dev eth0 proto kernel scope link src 172.31.4.4 > default via 192.168.123.1 dev eth0 src 172.31.4.4 > > Thanks much, > Gabriel |
From: Gabriel S. <gs...@gm...> - 2007-06-14 14:26:20
|
On 6/14/07, Paul Winder <Pau...@ta...> wrote: > After phase1 do you get a message like: > INFO: ISAKMP-SA established src-ip[port]-dest-ip[port] spi:... Yes: 2007-06-14 10:14:49: INFO: ISAKMP-SA established 192.168.123.234[500]-192.168.5.220[500] spi:674c477fbb657890:bb9ad2116e1095e9 > and what does setkey -PD show after phase 1? I added a statement to print this out at the top of my phase1_up script, and here's what I get: (per-socket policy) in none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=51 seq=1 pid=3074 refcnt=1 (per-socket policy) in none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=35 seq=2 pid=3074 refcnt=1 (per-socket policy) in none created: Jun 14 10:14:26 2007 lastused: Jun 14 10:14:49 2007 lifetime: 0(s) validtime: 0(s) spid=19 seq=3 pid=3074 refcnt=1 (per-socket policy) in none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=3 seq=4 pid=3074 refcnt=1 (per-socket policy) out none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=60 seq=5 pid=3074 refcnt=1 (per-socket policy) out none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=44 seq=6 pid=3074 refcnt=1 (per-socket policy) out none created: Jun 14 10:14:26 2007 lastused: Jun 14 10:14:49 2007 lifetime: 0(s) validtime: 0(s) spid=28 seq=7 pid=3074 refcnt=1 (per-socket policy) out none created: Jun 14 10:14:26 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=12 seq=0 pid=3074 refcnt=1 My phase1_up script sets up the routing and makes a bunch more calls to setkey. Debug output from racoon continues and is interleaved with output from the phase1_up script (so I guess racoon doesn't wait for the script to finish, or has multiple child processes running concurrently). Anyway, before the phase1_up script finishes, racoon prints these error messages: 2007-06-14 10:14:49: DEBUG: netlink signals update interface address list 2007-06-14 10:14:49: DEBUG: my interface: fe80::20b:dbff:fe7d:547d%eth0 (eth0) 2007-06-14 10:14:49: DEBUG: my interface: ::1 (lo) 2007-06-14 10:14:49: ERROR: unsuitable address: eth0 172.31.4.4 2007-06-14 10:14:49: DEBUG: my interface: 192.168.123.234 (eth0) 2007-06-14 10:14:49: DEBUG: my interface: 127.0.0.1 (lo) 2007-06-14 10:14:49: DEBUG: configuring default isakmp port. 2007-06-14 10:14:49: DEBUG: 4 addrs are configured successfully 2007-06-14 10:14:49: ERROR: failed to bind to address 127.0.0.1[500] (Address already in use). 2007-06-14 10:14:49: ERROR: failed to bind to address 128.2.120.66[500] (Address already in use). 2007-06-14 10:14:49: ERROR: failed to bind to address ::1[500] (Address already in use). 2007-06-14 10:14:49: ERROR: failed to bind to address fe80::20b:dbff:fe7d:547d%eth0[500] (Address already in use). 2007-06-14 10:14:49: ERROR: no address could be bound. 2007-06-14 10:14:49: DEBUG: pk_recv: retry[0] recv() 2007-06-14 10:14:49: DEBUG: get pfkey REGISTER message I wonder if a child instance of racoon tries to bind to sockets already bound by the parent racoon process ? Thanks, Gabriel |
From: Paul W. <Pau...@ta...> - 2007-06-14 14:47:49
|
Gabriel Somlo wrote: > On 6/14/07, Paul Winder <Pau...@ta...> wrote: > >> After phase1 do you get a message like: >> INFO: ISAKMP-SA established src-ip[port]-dest-ip[port] spi:... > > > Yes: > > 2007-06-14 10:14:49: INFO: ISAKMP-SA established > 192.168.123.234[500]-192.168.5.220[500] > spi:674c477fbb657890:bb9ad2116e1095e9 > >> and what does setkey -PD show after phase 1? > > You should have two entries like (well I do): 0.0.0.0/0[any] 192.168.65.52[any] any in prio def ipsec esp/tunnel/10.1.1.1-10.2.2.2/require created: Jun 14 15:38:58 2007 lastused: Jun 14 15:41:06 2007 lifetime: 0(s) validtime: 0(s) spid=640 seq=1 pid=14812 refcnt=8 192.168.65.52[any] 0.0.0.0/0[any] any out prio def ipsec esp/tunnel/10.2.2.2-10.1.1.1/require created: Jun 14 15:38:58 2007 lastused: Jun 14 15:41:06 2007 lifetime: 0(s) validtime: 0(s) spid=633 seq=2 pid=14812 refcnt=9 Maybe something is going wrong with the setkeys to create the spd entries.... |
From: Gabriel S. <gs...@gm...> - 2007-06-14 15:34:11
|
Paul, If I dump the output of 'setkey -PD' *after* the phase1_up script completes its work (i.e., all the setkey statements in there are done being executed), I do get something like what you mentioned: 0.0.0.0/0[any] 172.31.4.4[any] any in prio def ipsec esp/tunnel/192.168.5.220-192.168.123.234/require created: Jun 14 11:18:57 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=152 seq=1 pid=3076 refcnt=2 172.31.4.4[any] 0.0.0.0/0[any] any out prio def ipsec esp/tunnel/192.168.123.234-192.168.5.220/require created: Jun 14 11:18:57 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=145 seq=2 pid=3076 refcnt=2 Problem was I did 'setkey -PD' as the first thing in phase1_up, instead of the last, as I should have. So we're good there :) (not that I'm happy about that, it still doesn't work :( When I try to send traffic through the tunnel, racoon receives an acquire, which it ignores because it claims not to listen on 192.168.123.234 (something to do with the failure to bind to that address ? :) ). Running setkey -PD again now displays a lastused timestamp on the second entry. But no traffic went through the tunnel, and the ping I used quits out with a 'connect: resource temporarily unavailable'. Thanks, Gabriel Thanks, Gabriel On 6/14/07, Paul Winder <Pau...@ta...> wrote: > You should have two entries like (well I do): > > 0.0.0.0/0[any] 192.168.65.52[any] any > in prio def ipsec > esp/tunnel/10.1.1.1-10.2.2.2/require > created: Jun 14 15:38:58 2007 lastused: Jun 14 15:41:06 2007 > lifetime: 0(s) validtime: 0(s) > spid=640 seq=1 pid=14812 > refcnt=8 > 192.168.65.52[any] 0.0.0.0/0[any] any > out prio def ipsec > esp/tunnel/10.2.2.2-10.1.1.1/require > created: Jun 14 15:38:58 2007 lastused: Jun 14 15:41:06 2007 > lifetime: 0(s) validtime: 0(s) > spid=633 seq=2 pid=14812 > refcnt=9 > > Maybe something is going wrong with the setkeys to create the spd > entries.... > |
From: Joy L. <la...@au...> - 2007-06-18 19:14:16
|
On Thu, 2007-06-14 at 10:26 -0400, Gabriel Somlo wrote: > Anyway, before the phase1_up script finishes, racoon prints these > error messages: > > 2007-06-14 10:14:49: DEBUG: netlink signals update interface address list > 2007-06-14 10:14:49: DEBUG: my interface: fe80::20b:dbff:fe7d:547d%eth0 (eth0) > 2007-06-14 10:14:49: DEBUG: my interface: ::1 (lo) > 2007-06-14 10:14:49: ERROR: unsuitable address: eth0 172.31.4.4 > 2007-06-14 10:14:49: DEBUG: my interface: 192.168.123.234 (eth0) > 2007-06-14 10:14:49: DEBUG: my interface: 127.0.0.1 (lo) > 2007-06-14 10:14:49: DEBUG: configuring default isakmp port. > 2007-06-14 10:14:49: DEBUG: 4 addrs are configured successfully > 2007-06-14 10:14:49: ERROR: failed to bind to address 127.0.0.1[500] > (Address already in use). > 2007-06-14 10:14:49: ERROR: failed to bind to address > 128.2.120.66[500] (Address already in use). > 2007-06-14 10:14:49: ERROR: failed to bind to address ::1[500] > (Address already in use). > 2007-06-14 10:14:49: ERROR: failed to bind to address > fe80::20b:dbff:fe7d:547d%eth0[500] (Address already in use). > 2007-06-14 10:14:49: ERROR: no address could be bound. > 2007-06-14 10:14:49: DEBUG: pk_recv: retry[0] recv() > 2007-06-14 10:14:49: DEBUG: get pfkey REGISTER message > > I wonder if a child instance of racoon tries to bind to sockets > already bound by the parent racoon process ? Yes, I think it is definitely a problem that racoon cannot bind to your interface addresses... it won't recognize any ACQUIRES off these interfaces... thus necessary SAs may not get established. The error message "(Address already in use)" indicates that something else, possibly another racoon or IKE daemon is running or did not clean up... A quick look at the code indicates the establishment and binding of the addresses happen after the call to daemon()... so either another racoon or some other program is running using these ports or did not clean up. I suggest checking to see if another racoon or IKE daemon is running. Regards, Joy |
From: Gabriel S. <gs...@gm...> - 2007-06-20 12:45:09
|
On 6/18/07, Joy Latten <la...@au...> wrote: > The error message "(Address already in use)" indicates that something > else, possibly another racoon or IKE daemon is running or did not clean > up... OK, did a little more digging, and here's what happens: racoon negotiates phase1 with the ASA, they exchange keys, and everything's generally going along nicely. Then, racoon sends a mode config request to the ASA, and receives a reply containing all sorts of information (IP4_ADDRESS, DNS, ... UNITY_SPLIT_INCLUDE, and so on). In response to this, it executes the phase1_up script, which configures the ":1" alias on the interface, adds routes, and runs setkey. Racoon now gets signaled by netlink that interfaces were updated: DEBUG: netlink signals update interface address list and in response, calls check_rtsock() from session() in session.c. This closes all sockets, and immediately tries to reopen them. On linux, this fails because the kernel hasn't had time to mop up all the closing sockets. I added a sleep(10) inbetween isakmp_close() and grab_myaddrs() in check_rtsock(), and immediately stopped receiving the bind errors. However, now I have a new problem. Racoon runs the script, then re-does its sockets, and, for some weird reason, it keeps getting the same mode config reply from the ASA repeatedly, re-runs the phase1_up script every time it gets one, and eventually dies with a malloc error after the third or fourth one it receives. Thanks for all the help, Gabriel |
From: Paul W. <Pau...@ta...> - 2007-06-20 14:15:22
|
> > However, now I have a new problem. Racoon runs the script, then > re-does its sockets, and, for some weird reason, it keeps getting the > same mode config reply from the ASA repeatedly, re-runs the phase1_up > script every time it gets one, and eventually dies with a malloc error > after the third or fourth one it receives. The repeated mode config reply is a bug/operating difference between racoon and ciscos in general. I posted a large patch recently which added further support for xauth, it also included a fix for this problem. Inside isakmp_cfg_reply() you need to track the attributes received and send the same attrutes back as a ISAKMP_CFG_SET, but with void/null values. Paul |
From: Matthew G. <mg...@sh...> - 2007-06-20 16:01:35
|
On 6/20/2007, "Paul Winder" <Pau...@ta...> wrote: > >The repeated mode config reply is a bug/operating difference between >racoon and ciscos in general. > >I posted a large patch recently which added further support for xauth, >it also included a fix for this problem. > >Inside isakmp_cfg_reply() you need to track the attributes received and >send the same attrutes back as a ISAKMP_CFG_SET, but with void/null values. > This is an operational difference. I don't see anything in the modecfg draft that recommends this method of operation. An ASA will also stop sending the mode config attribute list if the peer proceeds to negotiate an IPSEC SA. Does your patch make returning the null attribute list configurable? -Matthew |
From: Paul W. <Pau...@ta...> - 2007-06-21 09:38:20
|
> > An ASA will also stop sending the mode config attribute list if the peer > proceeds to negotiate an IPSEC SA. Does your patch make returning the > null attribute list configurable? I didn't. That can be an exercise for the reader :-) |
From: Gabriel S. <gs...@gm...> - 2007-06-21 22:22:51
|
I tried Paul's patch (applied almost 100% cleanly to latest CVS, only one small change was needed). Turns out the mode config ack packet is sent too early in the conversation, and I never reach the point where I receive my tunnel IP, split-tunnel networks, and the rest of the config information. I think maybe the ack should be sent right after the script_hook() function is called from, e.g., isakmp_cfg_reply() in isakmp_cfg.c ? The other thing I tried was (in addition to a sleep(10) in check_rtsock() in session.c, which allows the old sockets to go away so new ones may be bound), to ignore all subsequent mode-config replies from the ASA after the first one that causes the phase1_up script to be run (dirty hack, added a flag that gets set right after script_hook() is called in isakmp_cfg_reply() in isakmp_cfg.c) This got me all the way to phase 2 negotiation, where racoon sends a set of six proposals (3des, blowfish, and aes encryption, each with either sha or md5 auth) and receives back an informational from the ASA telling it that all proposals were found unacceptable. Weird thing is, on the ASA I have crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac as the only thing I use, so it should have matched racoon's proposals... Thanks for any more ideas... Gabriel On 6/20/07, Paul Winder <Pau...@ta...> wrote: > The repeated mode config reply is a bug/operating difference between > racoon and ciscos in general. > > I posted a large patch recently which added further support for xauth, > it also included a fix for this problem. > > Inside isakmp_cfg_reply() you need to track the attributes received and > send the same attrutes back as a ISAKMP_CFG_SET, but with void/null values. |