Re: [strongSwan] xAuth request for VICI
Ok, thanks for the information.
Two final (quick) questions:
1) Is there alternative for 'leftfirewall=yes' in the VICI interface to
automatically setup iptables rules?
2) What is the syntax for loading a secret in via VICI. My current format (
`load_shared({'type': 'xauth', 'data': 'test : XAUTH "test"'})` ) says it
loads successfully but does not authenticate.
Thank you for your helping getting this setup.
Best,
Sam
On Fri, Feb 27, 2015 at 4:19 AM, Martin Willi wrote:
> Hi,
>
> > Your fix to use the ordered dictionary worked perfectly. Thank you very
> > much. It is now accepting vpn connections.
>
> Great. I'll check how we can mention that issue in the documentation.
>
> > Regarding the `vips` configuration, I thought that it was the replacement
> > for the `rightsourceip` option in ipsec.conf (obviously I misinterpreted
> > the documentation).
>
> No, the rightsourceip option is separated in swanctl.conf/vici to the
> pools and vips options for servers and clients, respectively.
>
> > It does work when I create a pool as you specified, but
> > if I want to give each connection a static pre-determined ip is there
> > anyway to do that other than creating a pool for each connection?
>
> No, currently there is no way to directly specify an address with the
> pools option. You have to use dedicated pools, or use a pool backend
> that supports static leases (attr-sql).
>
> Regards
> Martin
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] 60+ SAs listed in ipsec status output?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello Tom,
What are the expiry times for those SAs?
And do you have a log of a rekey event?
Mit freundlichen Grüßen/Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 25.02.2015 um 15:57 schrieb try...@rymes.com:
> I have a tunnel between two Strongswan boxes that is set to rekey IKE every 8
> hours and rekey the SA every 1 hour. Here is the local ipsec.conf (the other
> side is the same, but has a dozen other tunnels, too):
>
> [root@hudson ~]# cat /etc/ipsec.conf
> version 2
>
> conn %default
> keyingtries=%forever
>
> include /etc/ipsec.user.conf
>
> conn Data
> left=ipa.ddr.ess.a
> leftsubnet=192.168.0.0/21
> leftfirewall=yes
> lefthostaccess=yes
> right=ipa.ddr.ess.b
> rightsubnet=10.100.0.0/23
> leftcert=/var/ipfire/certs/hostcert.pem
> rightcert=/var/ipfire/certs/Datacert.pem
> leftid="@hosta.mydom.dom"
> rightid="@mydom.dom"
>
> ike=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp
>
> esp=aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256
> keyexchange=ikev2
> ikelifetime=8h
> keylife=1h
> compress=yes
> dpdaction=restart
> dpddelay=120
> dpdtimeout=30
> authby=rsasig
> leftrsasigkey=%cert
> rightrsasigkey=%cert
> auto=route
>
> For some reason, if I leave the machine to its own devices, the output of
> ipsec status ends up littered with old (?) SA entries, that make no sense to
> me. Why would this be happening?:
>
> Routed Connections:
> Data{4}: ROUTED, TUNNEL
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Security Associations (1 up, 0 connecting):
> Data[286]: ESTABLISHED 33 minutes ago, ipa.ddr.ess.a[C=US, ST=NH,
> O=Mydom, OU=Engineering Dept, CN=hosta.mydom.dom]...ipa.ddr.ess.b[C=US,
> ST=NH, O=Mydom, OU=Engineering Dept, CN=mydom.dom]
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c8107662_i c89e3611_o, IPCOMP
> CPIs: 43cf_i 36be_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: cb693600_i c09bb1e2_o, IPCOMP
> CPIs: b74b_i 2a3a_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: cf34c325_i c8ae364f_o, IPCOMP
> CPIs: 04c8_i db51_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c6450374_i c89d0fd0_o, IPCOMP
> CPIs: b2d5_i 8f17_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: ccb82be4_i cb8c6de5_o, IPCOMP
> CPIs: cc2f_i 7485_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c046292d_i cb9c5941_o, IPCOMP
> CPIs: e1ef_i eb0b_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c46c40fa_i c8cb22a6_o, IPCOMP
> CPIs: 7468_i 1a4e_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c7471719_i ceb7ebfb_o, IPCOMP
> CPIs: abd5_i 15fd_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c79e5c03_i c47d2958_o, IPCOMP
> CPIs: 3646_i 32ee_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c34675de_i c8e2a79b_o, IPCOMP
> CPIs: 268c_i b0c6_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c000d12c_i cb8c4f5f_o, IPCOMP
> CPIs: 48e4_i 10ff_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: cdf3f6f1_i c268a557_o, IPCOMP
> CPIs: 2d38_i 2aa2_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c79415e3_i c145e90e_o, IPCOMP
> CPIs: e71d_i 689e_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: cb6195e9_i c6e07cf3_o, IPCOMP
> CPIs: e0a9_i 71e5_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c47ffca9_i cbed8f2e_o, IPCOMP
> CPIs: 6fd0_i 1fc1_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: c64f97ef_i c848ff51_o, IPCOMP
> CPIs: 088f_i 474d_o
> Data{4}: 192.168.0.0/21 === 10.100.0.0/23
> Data{4}: INSTALLED, TUNNEL, ESP SPIs: cfc07514_i cddf8c9b_o, IPCOMP
> CPIs: 151a
Re: [strongSwan] HA plugin: stopping charon does not remove IKE_SA/CHILD_SA from other nodes
Thanks for your answer, I missed that point! Actually I'm running the cluster in active/passive mode (just 1 segment, two nodes). You're right: the monitoring/heartbeat is disabled since I already have an external tool to monitor the nodes. The external tool directly control the segment responsibility using the ha socket. In that particular configuration (no monitoring/heartbeat) stopping charon on the active node should clear the connections on the remote gateway (OK) and on the other node (not OK), right? Best Regards, Emeric - Mail original - De: "Martin Willi" À: "Emeric POUPON" Cc: users@lists.strongswan.org Envoyé: Vendredi 27 Février 2015 16:27:02 Objet: Re: [strongSwan] HA plugin: stopping charon does not remove IKE_SA/CHILD_SA from other nodes > When charon is stopped on one of the nodes, DELETE are sent to the remote > hosts: Actually, it should not if it has an active heartbeat connection with the other node. If a node knows that another node is active, it should deactivate all responsible segments locally before shutting down, and omit any delete messages. The other node takes over responsibility for all SAs. I haven't tested that code in a while, but it definitely did work if monitoring/heartbeat is active, see [1]. Regards Martin [1]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/ha/ha_segments.c;h=fc7d7a8b;hb=HEAD#l240 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] HA plugin: stopping charon does not remove IKE_SA/CHILD_SA from other nodes
> When charon is stopped on one of the nodes, DELETE are sent to the remote > hosts: Actually, it should not if it has an active heartbeat connection with the other node. If a node knows that another node is active, it should deactivate all responsible segments locally before shutting down, and omit any delete messages. The other node takes over responsibility for all SAs. I haven't tested that code in a while, but it definitely did work if monitoring/heartbeat is active, see [1]. Regards Martin [1]http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/ha/ha_segments.c;h=fc7d7a8b;hb=HEAD#l240 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] HA plugin: stopping charon does not remove IKE_SA/CHILD_SA from other nodes
Hello, I have set a HA cluster using strongswan 5.2.2. When charon is stopped on one of the nodes, DELETE are sent to the remote hosts: Feb 27 15:14:34 00[DMN] signal of type SIGINT received. Shutting down Feb 27 15:14:34 00[MGR] going to destroy IKE_SA manager and all managed IKE_SA's Feb 27 15:14:34 00[MGR] set driveout flags for all stored IKE_SA's Feb 27 15:14:34 00[MGR] wait for all threads to leave IKE_SA's Feb 27 15:14:34 00[MGR] delete all IKE_SA's Feb 27 15:14:34 00[IKE] queueing IKE_DELETE task ... Feb 27 15:14:34 00[IKE] sending DELETE for IKE_SA my_connection[1] ... Feb 27 15:14:34 00[IKE] IKE_SA my_connection[1] state change: DELETING => DESTROYING Feb 27 15:14:34 00[KNL] deleting SAD entry with SPI c098e83c ... Feb 27 15:14:34 00[KNL] deleted SAD entry with SPI c098e83c Feb 27 15:14:34 00[KNL] deleting SAD entry with SPI cfa1a139 ... However, the other members of the cluster are not notified of this deletion. When charon is restarted, it gets the already destroyed connections back from the passive nodes, but they have been destroyed on the remote gateway. This leads to quite complicated situations to understand. It sounds like a bug, what do you think? Emeric ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
Hello Martin, same client connects to other servers successfully, with same credentials. After I change server name - connection fails. and this happend only with one particular server, so according to your explanation either client didn't get XAuth request or server didn't get reply. I've just tried to compare tcpdumps from two machines (good and bad ones) and thet look similar except one string (with ip-proto-17) 14:44:09.253366 IP 46.211.137.122.44028 > 179.179.179.179.500: isakmp: phase 1 I ident 14:44:09.254387 IP 179.179.179.179.500 > 46.211.137.122.44028: isakmp: phase 1 R ident ... 14:44:12.269561 IP 46.211.137.122.43918 > 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:12.274524 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:12.274536 IP 179.179.179.179 > 46.211.137.122: ip-proto-17 14:44:12.274554 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 2/others R #6[E] 14:44:13.177956 IP 46.211.137.122.43918 > 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:13.178322 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:13.178334 IP 179.179.179.179 > 46.211.137.122: ip-proto-17 14:44:16.274884 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 2/others R #6[E] 14:44:16.997719 IP 46.211.137.122.43918 > 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:16.998089 IP 179.179.179.179.4500 > 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:16.998100 IP 179.179.179.179 > 46.211.137.122: ip-proto-17 Thanks for your help, looks like network issue, will digg in that direction. 27.02.2015, 16:50, "Martin Willi" : > Hi Denis >> 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] >> 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] >> (1660 bytes) >> 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) >> ] >> 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] >> (76 bytes) >> 10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1 > > strongSwan requests XAuth authentication from the client, but the client > does not seem to answer. Either it does not get the message, the user is > not entering the credentials in time, or more likely, it does not expect > an XAuth username/password request. > > Most likely your client is not configured to do XAuth, or it is one of > those clients that want to skip XAuth authentication during the ISAKMP > reauthentication procedure (iOS, OS X). We strictly require that, as we > think just skipping XAuth is a security issue. > > Regards > Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
Hi Denis > 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] > 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] > (1660 bytes) > 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] > 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] > (76 bytes) > 10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1 strongSwan requests XAuth authentication from the client, but the client does not seem to answer. Either it does not get the message, the user is not entering the credentials in time, or more likely, it does not expect an XAuth username/password request. Most likely your client is not configured to do XAuth, or it is one of those clients that want to skip XAuth authentication during the ISAKMP reauthentication procedure (iOS, OS X). We strictly require that, as we think just skipping XAuth is a security issue. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] deleting half open IKE_SA after timeout
Hello, I have several identicall servers (but in different datacenters), client can connect to any except one. configs are completely identical (ensured by cfengine, tripple re-checked manually), so probably that's not configuration issue. logs look like: Feb 27 13:58:34 s04001011709 charon: 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] Feb 27 13:58:34 s04001011709 charon: 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:34 s04001011709 charon: 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] Feb 27 13:58:34 s04001011709 charon: 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:38 s04001011709 charon: 10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1 Feb 27 13:58:38 s04001011709 charon: 10[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:38 s04001011709 charon: 12[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:38 s04001011709 charon: 12[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:38 s04001011709 charon: 12[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:41 s04001011709 charon: 13[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:41 s04001011709 charon: 13[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:41 s04001011709 charon: 13[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:44 s04001011709 charon: 15[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:44 s04001011709 charon: 15[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:44 s04001011709 charon: 15[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:45 s04001011709 charon: 14[IKE] sending retransmit 2 of request message ID 2234314252, seq 1 Feb 27 13:58:45 s04001011709 charon: 14[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:57 s04001011709 charon: 05[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:57 s04001011709 charon: 05[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:57 s04001011709 charon: 05[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:58 s04001011709 charon: 04[IKE] sending retransmit 3 of request message ID 2234314252, seq 1 Feb 27 13:58:58 s04001011709 charon: 04[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:59:02 s04001011709 charon: 07[JOB] deleting half open IKE_SA after timeout That's it. setting log level for NET and IKE to "2" do not give more info. Have no idea how to debug/where to digg. Help me please :) -- Denis ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] stateless high availability
Thanks Martin! At least I know that I need to find an another solution [ eg Virtual-IP on the remote end] Regards, > Subject: Re: [strongSwan] stateless high availability > From: mar...@strongswan.org > To: olivier_pele...@hotmail.com > CC: users@lists.strongswan.org > Date: Fri, 27 Feb 2015 10:29:18 +0100 > > Hi, > > > Is there a way to configure a device to connect to a gateway [ eg > > 10.1.1.254]. If that gateway fails [ detected via DPD],it would > > connect to 10.1.1.253 [ his backup gateway]? > > No, specifying fallback addresses is currently not implemented in > strongSwan. > > > I've tried with right=10.1.1.254,10.1.1.253 > > Specifying multiple addresses is supported, but it currently works only > for matching the endpoints of connection attempts to configurations. > > > it does not seems to work [ it expects an identity > > 10.1.1.254,10.1.1.253 on the remote. > > rightid defaults to right, so if you have more than a single address, > you should define rightid explicitly. But as said, having multiple > addresses in right currently does not what you intend. > > Regards > Martin > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] stateless high availability
Hi, > Is there a way to configure a device to connect to a gateway [ eg > 10.1.1.254]. If that gateway fails [ detected via DPD],it would > connect to 10.1.1.253 [ his backup gateway]? No, specifying fallback addresses is currently not implemented in strongSwan. > I've tried with right=10.1.1.254,10.1.1.253 Specifying multiple addresses is supported, but it currently works only for matching the endpoints of connection attempts to configurations. > it does not seems to work [ it expects an identity > 10.1.1.254,10.1.1.253 on the remote. rightid defaults to right, so if you have more than a single address, you should define rightid explicitly. But as said, having multiple addresses in right currently does not what you intend. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] multiple addresses for the left|right option
Hi, > I am wondering how the specification of multiple addresses in the left|right > option works. > right=134.111.75.171,134.111.75.172 The right option can take multiple addresses, but only to match the connection when responding to initiators. > For example, how many kernel policies I should have seen if I have the > left with one single address and the right with two specific address left/right does not directly specify the selectors/policies negotiated, leftsubnet/rightsubnet does. leftsubnet/rightsubnet default to %dynamic, which gets replaced dynamically with the peer endpoints (or an assigned virtual IP). So the selector does not get extended to what you configure in "right", but what addresses are used for the IKE exchange (usually just one of them). If you want to negotiate additional/different selectors, specify them in leftsubnet/rightsubnet instead. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] xAuth request for VICI
Hi, > Your fix to use the ordered dictionary worked perfectly. Thank you very > much. It is now accepting vpn connections. Great. I'll check how we can mention that issue in the documentation. > Regarding the `vips` configuration, I thought that it was the replacement > for the `rightsourceip` option in ipsec.conf (obviously I misinterpreted > the documentation). No, the rightsourceip option is separated in swanctl.conf/vici to the pools and vips options for servers and clients, respectively. > It does work when I create a pool as you specified, but > if I want to give each connection a static pre-determined ip is there > anyway to do that other than creating a pool for each connection? No, currently there is no way to directly specify an address with the pools option. You have to use dedicated pools, or use a pool backend that supports static leases (attr-sql). Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan retransmit request problem
Hi, > I'm trying to setup strongswan 5.2 but am experiencing problems where the > leftside can't seem to connect to the right side and keeps retransmitting > the request till it times out. Most likely this is a connectivity or firewalling issue. You should check where that IKE_SA_INIT message gets lost. Open up any firewall in between for UDP ports 500 and 4500 and ESP. > I do notice in the log file that this error occurs "unable to load 3 plugin > features (3 due to unmet dependencies)" but do not know if it is related to > the problem? It's not, this is just an unrelated warning. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] sonicwall with main mode
Hi, > rightid=001122334455667788 > *IDir '62.43.189.77' does not match to '001122334455667788*' Your Sonicwall uses '62.43.189.77' as its identity. Your strongSwan configuration strictly requires '0011223344556677880' as defined by rightid. Either change your Sonicwall or your strongSwan configuration to define the same identity for the Sonicwall. And the usual word of warning: Using psk + xauth is not recommended, as you can't use different PSK secrets in Main Mode for different clients. This allows any client to impersonate the gateway with that PSK. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
