Re: isakmpd only works if one side begins the communication
> it is more productive to make the .conf simpler, and > not more complex. more complex usually ends up in Great advice. > the 'Address' line within an is to be > interpreted as optional, so these seem to be two If I'm not mistaken, it's *optional* for Passive-connections=IPsec-clients,CONN-VPNPrueba2 but not > > [Phase 2] > > Connections=IPsec-clients,CONN-VPNPrueba2 ... > > 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. Try using the "Passive-connections= ..." on one of the VPN-peers only. > to blame the .confs. if i haven't been of much use so far, please I think you've been very helpful here. > switch the more predictable/stable/static peer to using > 'Passive-connections=' for the CONN-VPNPrueba. I would give this a shot as it is not going to hurt to try :) Mark T. Uemura OpenBSD Support Japan Inc. www.openbsd-support.com
Re: isakmpd only works if one side begins the communication
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" doesn't reference an . 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 on another [Phase 1] line - since both sides' "IPsec-clients" are the same, and both only specify an 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 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 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 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 DestinationPort Proto SA(Address/Proto/Type/Direction) 0.0.0.0/32 0 0/00 0 10.0.0.67/50/use/in 0/00 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 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 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 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 DestinationPort 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/requi
Re: isakmpd only works if one side begins the communication
> isakmpd.conf on one side: ... [Phase 2] -Connections= IPsec-clients,CONN-VPNPrueba2 +Passive-connections= IPsec-clients,CONN-VPNPrueba2 Try making this one change the isakmpd.conf on the VPN-peer that the clients will be connecting to. Mark T. Uemura OpenBSD Support Japan Inc. www.openbsd-support.com
Re: isakmpd only works if one side begins the communication
El Miircoles, 22 de Junio de 2005 15:33, jared r r spiegel escribis: > On Wed, Jun 22, 2005 at 02:01:43PM +0200, Abel Talaversn Estevez wrote: > > Is it normal? Can I solve it with a parameter like "Retransmit" or > > "Timeout"? I know that it happens something similar with D-Link > > Firewalls. > > need configs to answer accurately, please. > > shouldn't need to dinker with retransmit or timeout values., shouldn't > need to 'kickstart' the connection with a ping or so, unless it was > so-configured to begin with. > > jared > > - > > [ openbsd 3.7 GENERIC ( jun 10 ) // i386 ] isakmpd.conf on one side: [General] Exchange-max-time= 30 Check-interval= 30 DPD_check_interval= 30 [Phase 1] 10.0.0.57= PEER-VPNPrueba2 Default=ISAKMP-clients [Phase 2] Connections=IPsec-clients,CONN-VPNPrueba2 # Phase 1 mobile client peer sections # [ISAKMP-clients] Phase= 1 Transport= udp Configuration= Client-main-mode Authentication= vpnclientopenwired # Phase 2 mobile client connection sections ### [IPsec-clients] Phase= 2 Configuration= Client-quick-mode Local-ID= local-subnet Remote-ID= remote-client # Mobile client ID sections ### [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 # Mobile client modes # [Client-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Client-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-SUITE [Sucursal-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Sucursal-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-SUITE # Sucursales #PEER Section VPNPrueba2 [PEER-VPNPrueba2] Phase= 1 Transport= udp Address=10.0.0.57 Configuration= Sucursal-main-mode Authentication= hen3ex #CONNECTION SECTION VPNPrueba2 [CONN-VPNPrueba2] Phase= 2 ISAKMP-peer=PEER-VPNPrueba2 Configuration= Sucursal-quick-mode Local-ID= ID-LocalSubnet-VPNPrueba2 Remote-ID= ID-RemoteSubnet-VPNPrueba2 #Local ID Section [ID-LocalSubnet-VPNPrueba2] ID-type=IPV4_ADDR_SUBNET Network=10.0.40.0 Netmask=255.255.255.0 #Remote ID Section [ID-RemoteSubnet-VPNPrueba2] ID-type=IPV4_ADDR_SUBNET Network=10.0.10.0 Netmask=255.255.255.0 isakmpd.conf on the other side: [General] Exchange-max-time= 30 Check-interval= 30 DPD_check_interval= 30 [Phase 1] 10.0.0.67= PEER-VPNPrueba Default=ISAKMP-clients [Phase 2] Connections=IPsec-clients,CONN-VPNPrueba # Phase 1 mobile client peer sections # [ISAKMP-clients] Phase= 1 Transport= udp Configuration= Client-main-mode Authentication= vpnclientopenwired # Phase 2 mobile client connection sections ### [IPsec-clients] Phase= 2 Configuration= Client-quick-mode Local-ID= local-subnet Remote-ID= remote-client # Mobile client ID sections ### [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 # Mobile client modes # [Client-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Client-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-SUITE [Sucursal-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA [Sucursal-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-SUITE # Sucursales #PEER Section VPNPrueba [PEER-VPNPrueba] Phase= 1 Transport= udp Address=10.0.0.67 Configuration= Sucursal-main-mode Authentication= hen3ex #CONNECTION SECTION VPNPrueba [CONN-VPNPrueba] Phase= 2 ISAKMP-peer=PEER-VPNPrueba Configuration= Sucursal-quick-mode Local-ID= ID-LocalSubnet-VPNPrueba Remote-ID= ID-RemoteSubnet-VPNPrueba #Local ID Section [ID-LocalSubnet-VPNPrueba] ID-type=IPV4_ADDR_SUBNET Network=10.0.10.0 Netmask=255.255.255.0 #Remote ID Section [ID-RemoteSubnet-VPNPrueba] ID-type=IPV4_ADDR_SUBNET Network=10.0.40.0 Netmask=255.255.255.0 Any idea? I've been trying some values in check-interval and exchange-max-time with no success
Re: isakmpd only works if one side begins the communication
On Wed, Jun 22, 2005 at 02:01:43PM +0200, Abel Talaversn Estevez wrote: > > Is it normal? Can I solve it with a parameter like "Retransmit" or "Timeout"? > I know that it happens something similar with D-Link Firewalls. need configs to answer accurately, please. shouldn't need to dinker with retransmit or timeout values., shouldn't need to 'kickstart' the connection with a ping or so, unless it was so-configured to begin with. jared - [ openbsd 3.7 GENERIC ( jun 10 ) // i386 ]
isakmpd only works if one side begins the communication
Hi all, I'm working with a firewall running OpenBSD with isakmpd. When I want to connect 2 or more firewalls, 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. Is it normal? Can I solve it with a parameter like "Retransmit" or "Timeout"? I know that it happens something similar with D-Link Firewalls. Thanks!!
