[strongSwan] High availability configuration
unite
unite at openmailbox.org
Sat Feb 28 15:16:41 CET 2015
On 2015-02-26 12:43, unite wrote:
> On 2015-02-23 22:37, Noel Kuntze wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello Aleksey,
>>
>> Check if you have the ha module by looking at the contents of the
>> /usr/lib/ipsec/plugins/ directory.
>> A file called "libstrongswan-ha.so" must be there to be able to
>> support HA.
>>
>> It looks like your installation either does not have it, or it is
>> disabled because of settings in /etc/strongswan.d/.
>>
>>
>> The tunnel source address and the addresses on the vpn-linked subnet
>> should always be on the active node.
>> You need to maintain the addresses using vrrp or other mechanisms.
>> I am somewhat confused by your many interfaces. Of course you can have
>> the IP on any interface you want and use
>> dynamic routing protocols to. You only need to give the CLUSTERIP rule
>> the IP you want to loadbalance on.
>>
>> You can attach an unlimited number of IPs to an interface. iproute2
>> can do that. ifconfig can't, because it's
>> ancient.
>>
>> I do not know if the clusterip rule needs an interface. It is
>> plausible, that it needs one, as the IP
>> and the multicast mac need to be bound to an interface.
>>
>> I think the kernel patches are in newer default kernels, but I might
>> be wrong here.
>>
>> Mit freundlichen Grüßen/Regards,
>> Noel Kuntze
>>
>> GPG Key ID: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>
>> Am 23.02.2015 um 15:21 schrieb unite:
>>> So, i still can't get HA plugin working. It doesn't seem to appear in
>>> the list of loaded plugins and it doesn't synchronize SA state
>>> between the nodes. I haven't patched my kernel for clusterip as
>>> written in HA configuration guide, so I'm now trying to test
>>> active/passive configuration. I have also installed extra plugins but
>>> still no use. Strongswan i use is 5.2.1 from wheezy-backports debian
>>> repository.
>>>
>>> so the output of "ipsec statusall" is:
>>>
>>> ipsec statusall
>>> Status of IKE charon daemon (strongSwan 5.2.1, Linux
>>> 3.16.0-0.bpo.4-amd64, x86_64):
>>> uptime: 72 minutes, since Feb 23 15:00:24 2015
>>> malloc: sbrk 675840, mmap 0, used 515280, free 160560
>>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
>>> scheduled: 12
>>> loaded plugins: charon test-vectors ldap pkcs11 aes rc2 sha1 sha2
>>> md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8
>>> pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp agent
>>> xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve
>>> socket-default stroke updown
>>>
>>> /etc/strongswan.conf on Node1:
>>>
>>> charon {
>>> load_modular = yes
>>> plugins {
>>> include strongswan.d/charon/*.conf
>>> ha {
>>> local = 10.1.64.87
>>> remote = 10.1.64.21
>>> segment_count = 2
>>> fifo_interface = yes
>>> monitor = yes
>>> resync = yes
>>> load = yes
>>> }
>>> }
>>> }
>>>
>>> include strongswan.d/*.conf
>>>
>>> /etc/strongswan.conf on Node2:
>>>
>>> charon {
>>> load_modular = yes
>>> plugins {
>>> include strongswan.d/charon/*.conf
>>> ha {
>>> local = 10.1.64.21
>>> remote = 10.1.64.87
>>> segment_count = 2
>>> fifo_interface = yes
>>> monitor = yes
>>> resync = yes
>>> load = yes
>>> }
>>>
>>> }
>>> }
>>>
>>> include strongswan.d/*.conf
>>>
>>> Here is output in /var/log/syslog after "service ipsec restart":
>>>
>>> Feb 23 16:15:08 deb-suri charon: 00[DMN] Starting IKE charon daemon
>>> (strongSwan 5.2.1, Linux 3.16.0-0.bpo.4-amd64, x86_64)
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading ca certificates from
>>> '/etc/ipsec.d/cacerts'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading aa certificates from
>>> '/etc/ipsec.d/aacerts'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading ocsp signer
>>> certificates from '/etc/ipsec.d/ocspcerts'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading attribute
>>> certificates from '/etc/ipsec.d/acerts'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading crls from
>>> '/etc/ipsec.d/crls'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loading secrets from
>>> '/etc/ipsec.secrets'
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] expanding file expression
>>> '/var/lib/strongswan/ipsec.secrets.inc' failed
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loaded IKE secret for
>>> 10.1.64.87 10.1.64.21
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loaded IKE secret for
>>> 10.1.64.53 10.1.234.100
>>> Feb 23 16:15:09 deb-suri charon: 00[CFG] loaded IKE secret for
>>> 172.16.28.1 10.1.234.100
>>> Feb 23 16:15:09 deb-suri charon: 00[LIB] loaded plugins: charon
>>> test-vectors ldap pkcs11 aes rc2 sha1 sha2 md5 random nonce x509
>>> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey
>>> sshkey pem openssl gcrypt af-alg fips-prf gmp agent xcbc cmac hmac
>>> ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke
>>> updown
>>> Feb 23 16:15:09 deb-suri charon: 00[LIB] unable to load 3 plugin
>>> features (3 due to unmet dependencies)
>>> Feb 23 16:15:09 deb-suri charon: 00[LIB] dropped capabilities,
>>> running as uid 0, gid 0
>>> Feb 23 16:15:09 deb-suri charon: 00[JOB] spawning 16 worker threads
>>> Feb 23 16:15:09 deb-suri charon: 06[CFG] received stroke: add
>>> connection 'TESTCISCO'
>>>
>>> Follwed by tunnel initiations.
>>>
>>> Can anyone point me what's wrong in my setup? I can see "unable to
>>> load 3 plugin features" however how can I derive which are those
>>> plugins (so if HA is one of them) and which dependencies are unmet?
>>>
>>> Thanks in advance.
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJU64+JAAoJEDg5KY9j7GZYvf8QAJR5vKDL7cmI5u2Ewq0U4uqw
>> o9ZnrMaQDhzSrVQJqIZ8l8rVcOrdALL4ndKitJtioPtpSzRg1Hlng4fD9n6H5CDx
>> N1xQR8TVVAsGCe0ti6Oi3wh3yuZdIASBrM1iWH1eTwlqhrh/PfR2yy9TDTnHYtAP
>> GaC+WgSqe9CFV7fHqCWfGkBqCJscyWX8kq70aNZ3r8MRjoODfoSjl/wkZSK6jTCr
>> WL0MNppHovHF/tRFzpHjIgZdwGMe1pl+4KJ0B17U7l/VkOg9B1xwWMWCkM5TXOVL
>> yQmCbu329V5rbMxmc+pQn/0iFjIFwe4wUat0uF3SrbMuU1sT57ndDDPY1laGBlWl
>> Q0GDCY/WTV1WO7MolJtIvVkaZHkWdErtK51rwvDrxLcgnVo/+2FW2Vgh9fwOSbqe
>> UJja2h5ol64PhV/tIfNeVPDcQyzUP1Ucap/EkJYKjt6PHBp8sfj5sv/ApAZ63h3+
>> C93hs1tz9jD17fbOv/uYUj8PdXHcpMkTH7Nk26V9l7U7dQE0RBoqU4v8ujUzjQvg
>> fKVEdbp8HoEG9MI0Qm2I9kqAs/W0T7WwjXvo5vEY7kWI7lDioHsIKhaGq/qEP28z
>> HSV0AWpEHYYZUoWZOV07V2vKt9EGbEzGQwSfvg2uoPwmrWcxZvaO4YRZP9enwweg
>> N4iR0jPYmvfNC07kpqAh
>> =g/iV
>> -----END PGP SIGNATURE-----
> Hi Noel!
>
> I've found out how to start HA plugin - I also needed to install
> libcharon-extra-plugins package. I've got it running and it seems to
> work fine in Active/Passive mode except for the fact that i couldn't
> test failover correctly - I'm using ancient cisco 2600 in my lab
> (don't have anything else at the moment - will try to find another
> debian machine to test using strongswan) which supports only ikev1 and
> probably has some other drawbacks - so, when failover occurs,
> strongswan correctly changes SA state on the backup node from PASSIVE
> to ESTABLISHED - still traffic won't flow through the tunnel. At that
> moment I can see 3 ike SAs on cisco, so I guess when failover occurs
> something goes wrong inside it. When I do "clear crypto isakmp sa" on
> this cisco traffic instantly begins to flow through the tunnel. I'll
> check the behaviour with another debian machine using ikev1 and ikev2
> and let you know.
>
> I've made a picture regarding my interfaces. I've attached it to me
> mail and also uploaded it to fileshare:
> https://www.dropbox.com/s/00of6fd48fu3n6l/strongswan_dia.png?dl=0
>
> Probably it would be more clear on it. So the tunnel is built between
> 172.16.123.0 and 10.10.10.0, using the source IP 1.1.1.50 and
> destination of 3.3.3.3. Practically, in this configuration no one wil
> ask for ARP of 1.1.1.50 (except for those residing in vlan50 - but we
> don't care about them) - ISP1 and ISP2 routers, trying to reach any
> address in 1.1.1.0/24 subnet, will forward packets to 192.168.0.2 and
> 192.168.1.2 respectively, using multicast MAC-addresses of them. So
> the original question was - do I anyway need to configure clusterip on
> 1.1.1.50, even if no one will ask for it's arp and traffic destined
> for it would be recieved on 192.168.0.2 and 192.168.1.2 clusterips on
> external interfaces? I guess kernel patching is still needed (if the
> patch is not included in newer kernels) for ipsec packets not to be
> balanced by clusterip, even if them are received not on the tunnel
> source interface.
>
> Also I guess having conntrackd running is critical in such setup,
> because packets which went out for example through NODE1 (via
> clusetrip 172.16.123.1) might come back thorugh NODE2 (via clusetrip
> 192.168.0.2) so they might get dropped because NODE2 won't know
> anything about the established session.
>
> If to talk about active/passive mode, if I don't use clusterip at all
> - so let's assume vrrp is used on external/internal interfaces to
> assign the cluster IPs of 192.168.0.1,192.168.1.1 and 172.16.123.1, is
> it enough just to bind tunnel source 1.1.1.50 as aliases on vlan50
> interface on both nodes or do I still need to configure clusterip on
> it?
>
> Thanks.
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
I've tested a little bit more in my lab environment. And I found out
quite weird thing during failover between two nodes working in
active/passive mode. So' I still use cisco 2600 router as the remote
side of the tunnel, tunnel is using ikev1. So, tunnel initiation with
NODE1 passes correctly, SAs are created and trafic flows through it. The
second node shows the tunnel state as PASSIVE. Some output from node1:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (1 up, 0 connecting):
C2600[1]: ESTABLISHED 13 seconds ago,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[1]: IKEv1 SPIs: 8024c18d8720fee9_i* 412cc325d1dd2d9d_r,
pre-shared key reauthentication in 7 hours
C2600[1]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c2336cf7_i d228a330_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
rekeying in 45 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
at this time on node 2:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (1 up, 0 connecting):
C2600[1]: PASSIVE,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[1]: IKEv1 SPIs: 8024c18d8720fee9_i* 412cc325d1dd2d9d_r
C2600[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c2336cf7_i d228a330_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
rekeying in 44 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
Then I'm doing the following:
1) I shut down strongswan on node1 and transfer virtual IP which serves
as the bgp nexthop(tunnel source is on the other vlan and is always up
on both nodes) to NODE2 and propagate new ARP for that IP using arping.
NODE2 transfers the tunnel to ESTABLISHED state, but also appears some
"REKEYING". Like this:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (2 up, 0 connecting):
C2600[2]: ESTABLISHED 5 seconds ago,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[2]: IKEv1 SPIs: 9a03753045ba4e16_i* b84640d2d1dd2d9d_r,
pre-shared key reauthentication in 7 hours
C2600[2]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c2336cf7_i d228a330_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
rekeying in 41 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
C2600[1]: REKEYING,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[1]: IKEv1 SPIs: 8024c18d8720fee9_i* 412cc325d1dd2d9d_r
C2600[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1
Then the REKEYING state dissapears and I see the following on node2:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (1 up, 0 connecting):
C2600[2]: ESTABLISHED 22 seconds ago,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[2]: IKEv1 SPIs: 9a03753045ba4e16_i* b84640d2d1dd2d9d_r,
pre-shared key reauthentication in 7 hours
C2600[2]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c2336cf7_i d228a330_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 200 bytes_i (2 pkts, 1s
ago), 200 bytes_o (2 pkts, 1s ago), rekeying in 41 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
Also at this time (every time I transfer my tunnel between the nodes)
additional ISAKMP SA on cisco router is created. I can see that
obviously new IKE SAs are created at this time, REKEYING state
corresponds to the original IKE SA, initiated from the NODE1. Why does
this happen? Is it due to ikev1 being used or I've just miconfigured
something?
So the tunnel seems established at this moment, however no traffic would
flow through it. I can see ESP traffic (bidirectional, so cisco sends
ping and I guess the reply is sent back to it through the tunnel) coming
to NODE2 but pings are still timed out on cisco. And here is where the
weird thing comes. To let the traffic flow again I should start
strongswan on node1. As soon as strongswan synchronizes state traffic is
correctly forwarded through node2 - i can see it on tcpdump and can see
no tunneled traffic on node1. Ouput at this time from NODE1:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (1 up, 0 connecting):
C2600[1]: PASSIVE,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[1]: IKEv1 SPIs: 9a03753045ba4e16_i* b84640d2d1dd2d9d_r
C2600[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c7643abd_i d4b51431_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o,
rekeying in 44 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
Ouput from NODE2 remains the same:
Connections:
C2600: 172.16.28.1...10.1.234.100 IKEv1, dpddelay=30s
C2600: local: [172.16.28.1] uses pre-shared key authentication
C2600: remote: [10.1.234.100] uses pre-shared key
authentication
C2600: child: 172.25.25.0/24 === 192.168.1.0/24 TUNNEL,
dpdaction=hold
Security Associations (1 up, 0 connecting):
C2600[2]: ESTABLISHED 22 seconds ago,
172.16.28.1[172.16.28.1]...10.1.234.100[10.1.234.100]
C2600[2]: IKEv1 SPIs: 9a03753045ba4e16_i* b84640d2d1dd2d9d_r,
pre-shared key reauthentication in 7 hours
C2600[2]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
C2600{1}: INSTALLED, TUNNEL, ESP SPIs: c2336cf7_i d228a330_o
C2600{1}: AES_CBC_128/HMAC_SHA1_96, 200 bytes_i (2 pkts, 1s
ago), 200 bytes_o (2 pkts, 1s ago), rekeying in 41 minutes
C2600{1}: 172.25.25.0/24 === 192.168.1.0/24
And traffic flows as it should. If I try to transfer the tunnel back to
NODE1, the same thing happens - traffic doesn't flow until I start
strongswan on node 2 again, additional isakmp sa will be created on
cisco router. I'm almost sure that it is some kind of configuration
issue - however I don't know what's wrong.
Here is my config of NODE1:
/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charondebug="ike 2, knl 2, cfg 4, chd 2"
conn C2600
ikelifetime=8h
keylife=1h
type=tunnel
authby=secret
left=172.16.28.1
leftsubnet=172.25.25.0/24
right=10.1.234.100
rightsubnet=192.168.1.0/24
dpdaction=hold
dpddelay=30
dpdtimeout=150
ike=aes128-sha1-modp1024
esp=aes128-sha1
keyexchange=ikev1
auto=add
/etc/strongswan.conf
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
include strongswan.d/*.conf
/etc/strongswan.d/charon/ha.conf
ha {
local = 10.1.64.87
remote = 10.1.64.21
segment_count = 2
fifo_interface = yes
monitor = yes
resync = yes
load = yes
}
config on NODE2:
/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charondebug="ike 2, knl 2, cfg 2, chd 2"
conn C2600
ikelifetime=8h
keylife=1h
type=tunnel
authby=secret
left=172.16.28.1
leftsubnet=172.25.25.0/24
right=10.1.234.100
rightsubnet=192.168.1.0/24
dpdaction=hold
dpddelay=30
dpdtimeout=150
ike=aes128-sha1-modp1024
esp=aes128-sha1
keyexchange=ikev1
auto=add
/etc/strongswan.conf
# strongswan.conf - strongSwan configuration file
#
# Refer to the strongswan.conf(5) manpage for details
#
# Configuration changes should be made in the included files
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
include strongswan.d/*.conf
/etc/strongswan.d/charon/ha.conf
ha {
fifo_interface = yes
load = yes
local = 10.1.64.21
monitor = yes
remote = 10.1.64.87
resync = yes
segment_count = 2
}
Please help me.
Thanks in advance.
--
With kind regards,
Aleksey
More information about the Users
mailing list