ipsec.conf macros
Hello!
In transitioning from isakmpd.conf to ipsec.conf I want to make the
configuration file simple and readable by using macros.
However, I seems like I can not make use of macros in the way that I want.
Example:
host_a="192.168.1.1"
host_b="192.168.2.2"
host_list="{" $host_a $host_b "}"
host_a_copy=$host_a
list_copy=$host_list
Gives errors:
# ipsecctl -vnf ipsec_hosts.conf
ipsec_hosts.conf: 5: syntax error
ipsecctl: Syntax error in config file: ipsec rules not loaded
host_a = "192.168.1.1"
host_b = "192.168.2.2"
host_list = "{ 192.168.1.1 192.168.2.2 }"
host_a_copy = "192.168.1.1"
It gives me even more problem when I use macros with lists of networks:
network_a="192.168.1.0/24"
network_b="192.168.2.0/24"
network_a_copy=$network_a
network_list="{ 192.168.1.0/24 192.168.2.0/24 }"
network_list_copy=$network_list
network_list_1="{" $network_a $network_b "}"
network_list_1_copy=$network_list_1
# ipsecctl -vnf ipsec_networks.conf
ipsec_networks.conf: 3: syntax error
ipsec_networks.conf: 5: syntax error
ipsec_networks.conf: 6: syntax error
ipsec_networks.conf: 7: macro 'network_list_1' not defined
ipsec_networks.conf: 7: syntax error
ipsecctl: Syntax error in config file: ipsec rules not loaded
network_a = "192.168.1.0/24"
network_b = "192.168.2.0/24"
network_list = "{ 192.168.1.0/24 192.168.2.0/24 }"
Is is supposed to work, or is it a bug? Or is there another way of doing it,
am I doing it wrong?
Thank you,
Jakob Alvermark
jakob.alverm...@bsdlabs.com
BSDLabs AB
Solna, Sweden
556759-7652
Re: IPSEC tunnels failing intermittently
Has anyone filed a bug report or should I send this to bugs@? Regards, Jakob Alvermark On 6 maj 2011, at 11:33, Jakob Alvermark wrote: > A little more info: > > I have now ENCDEBUG enabled on both ends in the lab. > When one tunnel fails I get the same error on both machines: > > May 4 12:27:55 test1 /bsd: esp_input_cb(): authentication failed for packet > in SA xxx.xxx.xxx.97/84be7b20 > > May 4 12:27:18 test2 /bsd: esp_input_cb(): authentication failed for packet > in SA xxx.xxx.xxx.99/da1d3abb > > ipsecctl -v -sa give no hints, everything looks normal: > > esp tunnel from xxx.xxx.xxx.99 to xxx.xxx.xxx.97 spi 0x84be7b20 auth > hmac-sha2-256 enc aes >sa: spi 0x84be7b20 auth hmac-sha2-256 enc aes >state mature replay 16 flags 4 >lifetime_cur: alloc 0 bytes 7968 add 1304504831 first 1304504875 >lifetime_hard: alloc 0 bytes 0 add 1200 first 0 >lifetime_soft: alloc 0 bytes 0 add 1080 first 0 >address_src: xxx.xxx.xxx.99 >address_dst: xxx.xxx.xxx.97 >identity_src: type prefix id 0: xxx.xxx.xxx.99/32 >identity_dst: type prefix id 0: xxx.xxx.xxx.97/32 >src_mask: 255.255.255.0 >dst_mask: 255.255.255.0 >protocol: proto 0 flags 0 >flow_type: type use direction in >src_flow: 192.168.31.0 >dst_flow: 192.168.1.0 >remote_auth: type rsa > > esp tunnel from xxx.xxx.xxx.97 to xxx.xxx.xxx.99 spi 0xda1d3abb auth > hmac-sha2-256 enc aes >sa: spi 0xda1d3abb auth hmac-sha2-256 enc aes >state mature replay 16 flags 4 >lifetime_cur: alloc 0 bytes 48864 add 1304504837 first 1304504838 >lifetime_hard: alloc 0 bytes 0 add 1200 first 0 >lifetime_soft: alloc 0 bytes 0 add 1080 first 0 >address_src: xxx.xxx.xxx.97 >address_dst: xxx.xxx.xxx.99 >identity_src: type prefix id 0: xxx.xxx.xxx.97/32 >identity_dst: type prefix id 0: xxx.xxx.xxx.99/32 >src_mask: 255.255.255.0 >dst_mask: 255.255.255.0 >protocol: proto 0 flags 0 >flow_type: type use direction in >src_flow: 192.168.1.0 >dst_flow: 192.168.31.0 >remote_auth: type rsa > > > On 2 maj 2011, at 21:59, MG wrote: > >> On 5/2/2011 12:13 PM, Vijay Sankar wrote: >>> Per olof Ljungmark wrote: >>>> On 05/02/11 18:08, Robert wrote: >>>>> Hi, >>>>> >>>>> Same here, but between 2 hosts in the same subnet (very basic network >>>>> setup). >>>>> I was also waiting for 4.9 (and time to investigate...) >>>> >>>> We see same behaviour on 4.9 so upgrading will not help. >>>> >>>>> On Mon, 2 May 2011 13:30:34 + (UTC) >>>>> Stuart Henderson wrote: >>>>> >>>>>> I see something similar which I've been trying to track down but not >>>>>> really succeeding. The thing we have in common is multiple subnets, >>>>>> I wonder if this is a factor... >>>>>> >>>>>> >>>>>> (and this setup has always been post-4.4 On 2011-05-02, Jakob Alvermark > wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am getting some strange problems with IPSEC tunnels. >>>>>>> There are 5 sites connected using IPSEC tunnels, which used to work > perfectly, >>>>>>> but since upgrading to 4.8 (from 4.4), >>>>>>> tunnels started failing, seemly at random intervals. >>>>>>> To investigate I set up two machines in the lab and they exhibit the > same >>>>>>> behavior: >>>>>>> After a seemingly random amount of time, when there is a renegotiation > of an >>>>>>> SA due to its lifetime expired, >>>>>>> traffic will stop flowing (I have a ping running). 'ipsecctl -sa' and > 'netstat >>>>>>> -rn' shows everything as normal. >>>>>>> When that SA lifetime expires and a new SA is negotiated it comes back > again. >>>>>>> >>>>>>> I recompiled the kernel with 'option ENCDEBUG' and set > net.inet.ip.encdebug=1 >>>>>>> and when it fails >>>>>>> I get 'esp_input_cb(): authentication failed for packet in SA >>>>>>> xxx.xxx.xxx.97/6e68c6ae' >>>>>>> >>>>>>> The machines are installed with stock OpenBSD 4.8, nothing special > about the >>>>>>> conf
Re: IPSEC tunnels failing intermittently
A little more info:
I have now ENCDEBUG enabled on both ends in the lab.
When one tunnel fails I get the same error on both machines:
May 4 12:27:55 test1 /bsd: esp_input_cb(): authentication failed for packet
in SA xxx.xxx.xxx.97/84be7b20
May 4 12:27:18 test2 /bsd: esp_input_cb(): authentication failed for packet
in SA xxx.xxx.xxx.99/da1d3abb
ipsecctl -v -sa give no hints, everything looks normal:
esp tunnel from xxx.xxx.xxx.99 to xxx.xxx.xxx.97 spi 0x84be7b20 auth
hmac-sha2-256 enc aes
sa: spi 0x84be7b20 auth hmac-sha2-256 enc aes
state mature replay 16 flags 4
lifetime_cur: alloc 0 bytes 7968 add 1304504831 first 1304504875
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
address_src: xxx.xxx.xxx.99
address_dst: xxx.xxx.xxx.97
identity_src: type prefix id 0: xxx.xxx.xxx.99/32
identity_dst: type prefix id 0: xxx.xxx.xxx.97/32
src_mask: 255.255.255.0
dst_mask: 255.255.255.0
protocol: proto 0 flags 0
flow_type: type use direction in
src_flow: 192.168.31.0
dst_flow: 192.168.1.0
remote_auth: type rsa
esp tunnel from xxx.xxx.xxx.97 to xxx.xxx.xxx.99 spi 0xda1d3abb auth
hmac-sha2-256 enc aes
sa: spi 0xda1d3abb auth hmac-sha2-256 enc aes
state mature replay 16 flags 4
lifetime_cur: alloc 0 bytes 48864 add 1304504837 first 1304504838
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
address_src: xxx.xxx.xxx.97
address_dst: xxx.xxx.xxx.99
identity_src: type prefix id 0: xxx.xxx.xxx.97/32
identity_dst: type prefix id 0: xxx.xxx.xxx.99/32
src_mask: 255.255.255.0
dst_mask: 255.255.255.0
protocol: proto 0 flags 0
flow_type: type use direction in
src_flow: 192.168.1.0
dst_flow: 192.168.31.0
remote_auth: type rsa
On 2 maj 2011, at 21:59, MG wrote:
> On 5/2/2011 12:13 PM, Vijay Sankar wrote:
>> Per olof Ljungmark wrote:
>>> On 05/02/11 18:08, Robert wrote:
>>>> Hi,
>>>>
>>>> Same here, but between 2 hosts in the same subnet (very basic network
>>>> setup).
>>>> I was also waiting for 4.9 (and time to investigate...)
>>>
>>> We see same behaviour on 4.9 so upgrading will not help.
>>>
>>>> On Mon, 2 May 2011 13:30:34 + (UTC)
>>>> Stuart Henderson wrote:
>>>>
>>>>> I see something similar which I've been trying to track down but not
>>>>> really succeeding. The thing we have in common is multiple subnets,
>>>>> I wonder if this is a factor...
>>>>>
>>>>>
>>>>> (and this setup has always been post-4.4 On 2011-05-02, Jakob Alvermark
wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am getting some strange problems with IPSEC tunnels.
>>>>>> There are 5 sites connected using IPSEC tunnels, which used to work
perfectly,
>>>>>> but since upgrading to 4.8 (from 4.4),
>>>>>> tunnels started failing, seemly at random intervals.
>>>>>> To investigate I set up two machines in the lab and they exhibit the
same
>>>>>> behavior:
>>>>>> After a seemingly random amount of time, when there is a renegotiation
of an
>>>>>> SA due to its lifetime expired,
>>>>>> traffic will stop flowing (I have a ping running). 'ipsecctl -sa' and
'netstat
>>>>>> -rn' shows everything as normal.
>>>>>> When that SA lifetime expires and a new SA is negotiated it comes back
again.
>>>>>>
>>>>>> I recompiled the kernel with 'option ENCDEBUG' and set
net.inet.ip.encdebug=1
>>>>>> and when it fails
>>>>>> I get 'esp_input_cb(): authentication failed for packet in SA
>>>>>> xxx.xxx.xxx.97/6e68c6ae'
>>>>>>
>>>>>> The machines are installed with stock OpenBSD 4.8, nothing special
about the
>>>>>> configuration.
>>>>>> ipsec.conf is very simple, just one line:
>>>>>>
>>>>>> ike esp from {192.168.1.9/24 172.16.1.0/24} to {192.168.31.0/24
>>>>>> 192.168.32.254} local xxx.xxx.xxx.97 peer xxx.xxx.xxx.99
>>>>>>
>>>>>> Public keys copied across, isakmpd started with flags "-K -v"
>>>>>>
>>>>>> Does anyone have any ideas about this?
>>>>>>
>>>>>> Thank you
>>>>>>
>
IPSEC tunnels failing intermittently
Hi,
I am getting some strange problems with IPSEC tunnels.
There are 5 sites connected using IPSEC tunnels, which used to work perfectly,
but since upgrading to 4.8 (from 4.4),
tunnels started failing, seemly at random intervals.
To investigate I set up two machines in the lab and they exhibit the same
behavior:
After a seemingly random amount of time, when there is a renegotiation of an
SA due to its lifetime expired,
traffic will stop flowing (I have a ping running). 'ipsecctl -sa' and 'netstat
-rn' shows everything as normal.
When that SA lifetime expires and a new SA is negotiated it comes back again.
I recompiled the kernel with 'option ENCDEBUG' and set net.inet.ip.encdebug=1
and when it fails
I get 'esp_input_cb(): authentication failed for packet in SA
xxx.xxx.xxx.97/6e68c6ae'
The machines are installed with stock OpenBSD 4.8, nothing special about the
configuration.
ipsec.conf is very simple, just one line:
ike esp from {192.168.1.9/24 172.16.1.0/24} to {192.168.31.0/24
192.168.32.254} local xxx.xxx.xxx.97 peer xxx.xxx.xxx.99
Public keys copied across, isakmpd started with flags "-K -v"
Does anyone have any ideas about this?
Thank you
Jakob Alvermark
jakob.alverm...@bsdlabs.com
BSDLabs AB
Solna, Sweden
556759-7652
