On Wed, Jun 22, 2005 at 04:15:19PM +0200, Abel Talaversn Estevez wrote: > > [General] > Exchange-max-time= 30 > Check-interval= 30 > DPD_check_interval= 30
if you're certain those are what you need to use for one reason or another, then you need to use them :), but > I've been trying some values in check-interval and exchange-max-time with no > success if you tried them to see if it would contribute to solving the trouble/issue you're seeing, i would suggest getting rid of them. i am not an expert on isakmpd, by any means, but in my experience, if i am trying to diagnose an unexpected behaviour, i find it is more productive to make the .conf simpler, and not more complex. more complex usually ends up in a period of frustration where you go in and twiddle a bunch of knobs at one time and try again, and then twiddle more knobs, etcetc.. i found i would not use Scientific Method and only change 1 thing at a time because there were so many damn things to try changing ( which is because i would make the .conf so complex ) naturally, twiddle after you are achieving expected results, but in the meantime, comment out the knobs :P > [Phase 1] > 10.0.0.57= PEER-VPNPrueba2 > Default= ISAKMP-clients . > [Phase 2] > Connections= IPsec-clients,CONN-VPNPrueba2 on both sides, the "IPsec-clients" <IPsec-connection> doesn't reference an <ISAKMP-peer>. you do have a 'Default' in the [Phase 1] sections on each, referencing the "ISAKMP-clients" peer, but from my understanding, 'Default' is only used for reference on _incoming_ connections not otherwise referenced by an <IP-address> on another [Phase 1] line - since both sides' "IPsec-clients" are the same, and both only specify an <ISAKMP-peer> via the 'Default' line, it would seem that in effect, both the "IPsec-clients" connection is acting passive on both sides. in my isakmpd.conf, i have nothing in the [Phase 1] section, and all my [Phase 2] connections reference <ISAKMP-peers> who have IPs in them. this may be setting me up for an unexpected result, but i have not seen any thus far. to be fair, it seems like the 'Address' line within an <ISAKMP-peer> is to be interpreted as optional, so these seem to be two different ways to accomplish the same goal in one scenario, and then also each of them could have a use that changes the scope of the <ISAKMP-peer> in a way that the other doesn't. for the : > [local-subnet] > ID-type= IPV4_ADDR_SUBNET > Network= 0.0.0.0 > Netmask= 0.0.0.0 > > [remote-client] > ID-type= IPV4_ADDR > Address= 0.0.0.0 sections, are those sanitized/obfuscated IPs, or are the IPs in the configs really all 0s? i'll assume that in the configs on the firewalls they're not all 0s. if 10.0.0.67 proposed those addresses to 10.0.0.57, and 10.0.0.57 accepted them, the flow would (i believe) look like this in 'netstat -rnf encap': Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) 0.0.0.0/32 0 0/0 0 0 10.0.0.67/50/use/in 0/0 0 0.0.0.0/32 0 0 10.0.0.67/50/require/out which probably won't do anything unless you really are sending traffic to 0.0.0.0/32 so, if they're actually IPs other than 0.0.0.0 for the "remote-client" section, and you did have an <ISAKMP-peer> referenced in the "IPsec-clients" part, the results would probably be unpredictable if that isakmpd tried to make a connection to more than one other, as then it would be trying to establish two flows with the same Encap Source and Destination ( which i believe doesn't jive even if the SA address is different. i know i've tried to do something like this before, and it ended up either constantly over- writing the encap flow with the most-newly-acquired one, or it refused to make a new one by virtue of there already being one. perhaps the former is true for with both flows are from isakmpd, and the latter when there is an initial flow created by ipsecadm.. ) given that the "IPsec-clients" gets an <ISAKMP-peer> by virtue of not having one (and therefore matching 'Default', which is only for incoming (afaik), it would seem that that connection is meant to be of a passive nature, and then usually geared towards having more than one possible person come in at a time, but i might be wrong about the intended use of the "IPsec-clients" connection. anyway, moving to the "CONN-VPNPrueba2" section. in [Phase 1] you say that 10.0.0.57 is to be interpreted as the <ISAKMP-peer> PEER-VPNPrueba2 who is configured with a psk an an expected address. once 10.0.0.67 and 10.0.0.57 have established their flow, it would look like this on .57's side: Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) 10.0.40/24 0 10.0.10/24 0 0 10.0.0.67/50/use/in 10.0.10/24 0 10.0.40/24 0 0 10.0.0.67/50/require/out which seems fine. you mention: > I can see the tunnels via: "netstat -rn | grep > encap" but the only way to begin the real communication is starting it by one > of the sides. If a try to begin with the other side it doesn't work until I > do a ping (or some kind of communication) from the other side. so at that point, you have your flow ok, and then, for example, 10.0.10.1 is unable to ping 10.0.40.1 until something *from* 10.0.40/24 comes down the pipe destined for 10.0.10/24? (assuming you're talking about 10.0.0.57 having the trouble). if you have just recently established the connection (killed / started isakmpd on both sides, for example), and the flow comes up, is that the behaviour, or is it only the behaviour after some period of inactivity? if i got the trouble correct two paragraphs ago, is the trouble also the same from the other side? ... i suppose it couldn't be as in the 'i get it to work by' section, you mention having to kickstart it by having one certain side make the first traffic... it's a long shot, but i would be interested in seeing the output of 'netstat -rnf inet | grep [^0-9]10\.' on both hosts prior to starting isakmpd, after starting it and having the encap flow, and after things working OK., although that might not be informative. i don't know if you are having the trouble for any IP in the respective /24s, or only on the gateways. if it is only on the gateways, i assume you have an alias for each Encap Network on the respective gateway. maybe 10.0.0.57 has an alias on an interface for 10.0.10.1. if 10.0.0.57 does not have an inet route for 10.0.40.0/24, any host on 10.0.40.0/24 will be able to ping 10.0.10.1, but 10.0.0.57 will not be able to ping any host on 10.0.40.0/24 *unless* you specify the source IP with '-I 10.0.10.1', assuming it doesn't have an inet route. ( that has shown up on the lists tons of times, but since i don't know if that's exactly what you're trying to do, i'll just make a passing mention of it ) otherwise it doesn't seem like there's any indication about why to blame the .confs. if i haven't been of much use so far, please clarify the scope of the trouble (is it at any time after the flows come up, including immediatly after?; is the trouble from any host on one /24 to any other host in the other /24, or is the trouble only between the VPN peers themselves?; is it always the same peer who has the trouble ( eg .57 always can't ping 10.0.40/24 until something comes from .67 destined for 10.0.10/24 and arrives at .57?) if the two firewalls are essentially peers, as far as usage is concerned, and they should always maintain connectivity to one another, it should be ok to leave the 'Connections=' lines in the [Phase 2] section as they are (although i am still wondering about the purpose of "IPsec-clients"). if one of the peers is on an unpredictable/troublesome link, or hops around physically (laptop or something..), then it would make absolute sense to switch the more predictable/stable/static peer to using 'Passive-connections=' for the CONN-VPNPrueba. jared - [ openbsd 3.7 GENERIC ( jun 10 ) // i386 ]
