[strongSwan] NATing around a subnet conflict
Can anyone point me in the right direction to getting traffic routed
across a site-site tunnel in a scenario where there is a subnet conflict?
Basically, our local subnet (10.100.0.0/23) conflicts with one on the
remote side, so we need to use NAT to trick the other side into seeing
us as 10.100.0.252/23. We have configured the tunnel and brought it up
so that this is the output of "ipsec status tunnelname"
[root@myhost ~]# ipsec status tunnelname
Security Associations (53 up, 0 connecting):
tunnelname[6102]: ESTABLISHED 107 minutes ago,
xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[yyy.yyy.yyy.yyy]
tunnelname{10971}: INSTALLED, TUNNEL, reqid 36, ESP SPIs: ced441ef_i
2dc9af95_o
tunnelname{10971}: 10.100.252.0/23 === 10.210.2.0/23
Now, I know that I need some SNAT/DNAT/? magic to tell the local
machine where to send the traffic and how to translate it, but I'm in
over my head.
Any help and pointers to the appropriate documentation would be appreciated.
Many thanks,
Tom
Re: [strongSwan] KEY_ID encoding
Hi Tobias,
this is what I see in logs:
b-test strongswan: 10[CFG] <25> looking for peer configs matching
server-side[%any]...client-side[ciscoasa]
b-test charon-systemd[130481]: looking for peer configs matching
server-side[%any]...client-side[ciscoasa]
b-test strongswan: 10[CFG] <25> peer config "ikev2-eap", ike match: 1052
(server-side...%any IKEv2)
b-test strongswan: 10[CFG] <25> local id match: 1 (ID_ANY: )
b-test strongswan: 10[CFG] <25> remote id match: 1 (ID_KEY_ID:
63:69:73:63:6f:61:73:61)
b-test strongswan: 10[CFG] <25> candidate "ikev2-eap", match: 1/1/1052
(me/other/ike)
b-test strongswan: 10[CFG] <25> peer config "ikev2-psk-whl", ike match: 1052
(server-side...%any IKEv2)
b-test strongswan: 10[CFG] <25> local id match: 1 (ID_ANY: )
b-test strongswan: 10[CFG] <25> remote id match: 0 (ID_KEY_ID:
63:69:73:63:6f:61:73:61)
b-test strongswan: 10[CFG] <25> peer config "ikev2-psk-ciscoasa", ike match:
1052 (server-side...%any IKEv2)
b-test strongswan: 10[CFG] <25> local id match: 1 (ID_ANY: )
b-test strongswan: 10[CFG] <25> remote id match: 0 (ID_KEY_ID:
63:69:73:63:6f:61:73:61)
b-test strongswan: 10[CFG] selected peer config 'ikev2-eap'
There are three connections:
connections {
ikev2-eap {
remote_addrs = %any
local { ... }
remote {
auth = eap-radius
id = %any
eap_id = %any
}
}
ikev2-whl {
remote_addrs = x.x.x.x
local { ... }
remote {
auth = psk
id = x.x.x.x
}
}
ikev2-cisoasa {
remote_addrs = %any
local { ... }
remote {
auth = psk
id = @#636973636f617361
# id = ciscoasa
# id = @#ciscoasa
}
}
}
It seems, remote side sends ID_KEY_ID: 63:69:73:63:6f:61:73:61, but no
one of three IDs matches received ID.
On the other hand, when I switch to FQDN ID
connections {
[ ... ]
ikev2-cisoasa {
remote_addrs = %any
local { ... }
remote {
auth = psk
id = ciscoasa
}
}
}
I see the correct behavior:
b-test strongswan: 08[CFG] <38> looking for peer configs matching
server-side[%any]...client-side[ciscoasa]
b-test strongswan: 08[CFG] <38> peer config "ikev2-eap", ike match: 1052
(server-side...%any IKEv2)
b-test strongswan: 08[CFG] <38> local id match: 1 (ID_ANY: )
b-test strongswan: 08[CFG] <38> remote id match: 1 (ID_FQDN:
63:69:73:63:6f:61:73:61)
b-test strongswan: 08[CFG] <38> candidate "ikev2-eap", match: 1/1/1052
(me/other/ike)
b-test strongswan: 08[CFG] <38> peer config "ikev2-psk-194_44_66_2", ike match:
1052 (server-side...%any IKEv2)
b-test strongswan: 08[CFG] <38> local id match: 1 (ID_ANY: )
b-test strongswan: 08[CFG] <38> remote id match: 0 (ID_FQDN:
63:69:73:63:6f:61:73:61)
b-test strongswan: 08[CFG] <38> peer config "ikev2-psk-ciscoasa", ike match:
1052 (server-side...%any IKEv2)
b-test strongswan: 08[CFG] <38> local id match: 1 (ID_ANY: )
b-test strongswan: 08[CFG] <38> remote id match: 20 (ID_FQDN:
63:69:73:63:6f:61:73:61)
b-test strongswan: 08[CFG] <38> candidate "ikev2-psk-ciscoasa", match:
1/20/1052 (me/other/ike)
b-test strongswan: 08[CFG] selected peer config
'ikev2-psk-ciscoasa'
I will appreciate any suggestions on how to work around this issue.
Thank you.
On 14.09.2020 11:56, Tobias Brunner wrote:
Hi Volodymyr,
do not work - StrongSwan do not consider this connection when choosing
between few.
Increase the log level for cfg to 3 [1] to see details about the matched
identities and read or send the log.
What is the right way to describe id for PSK connection where remote
part uses key-id type, e.g. on Cisco it is "crypto isakmp identity
key-id aa"?
Don't know what Cisco will send if you do that, so no idea. You'll see
that in the log.
And which id need to be used in 'secrets' section to achieve the result?
Should it be
It must match the identity value and type you configure in the remote
section.
Regards,
Tobias
[1] https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration
--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
Re: [strongSwan] Android client - Use MSCHAPv2
Thanks a lot for your answer. I just found out a working (though not perfect) solution. We have the default Charon configuration, which basically loads all modules Charon was built with. I spent hours tweaking charon's configuration to have eap-dynamic prefer mschapv2, disable eap-md5, etc. With no result: the server would still propose Eap-md5 to the client, the client would accept it, and the server would fail. I just found out that it is actually radius that chooses the default EAP method. Everything works fine now that mschapv2 is the default radius EAP method. Never hit that issue before because in all our other (Linux) is clients we have access to the ipsec.conf directly, so we directly set leftauth to eap-mschapv2 and the client will happily Nak everything else. Still, I agree with you that only mschapv2 should be proposed by the server. I just have to find out how to do that.. Charon does not seem to have any incidence on what is proposed to the client. My understanding now is radius is responsible for all of the possible EAP methods. Am I correct? On Mon, Sep 14, 2020, 20:56 Tobias Brunner wrote: > Hi, > > > The feature list explicitly states that the android client supports > > EAP-MSCHAPv2, but I see no way to actually enforce that on the client, > > and the authentication keeps failing because EAP-MD5 is used. > > The (AAA) server is the one initiating the EAP method, the client can't > explicitly choose the method (it could reject the initiated method and > send a list of supported ones, but the Android client has no option to > explicitly reject one of the username/password methods). So how is > EAP-MD5 failing? Why is the server initiating a method that then fails? > And why don't you just let the server initiate EAP-MSCHAPv2 if you want > to use that? > > Regards, > Tobias >
Re: [strongSwan] Android client - Use MSCHAPv2
Hi, > The feature list explicitly states that the android client supports > EAP-MSCHAPv2, but I see no way to actually enforce that on the client, > and the authentication keeps failing because EAP-MD5 is used. The (AAA) server is the one initiating the EAP method, the client can't explicitly choose the method (it could reject the initiated method and send a list of supported ones, but the Android client has no option to explicitly reject one of the username/password methods). So how is EAP-MD5 failing? Why is the server initiating a method that then fails? And why don't you just let the server initiate EAP-MSCHAPv2 if you want to use that? Regards, Tobias
[strongSwan] Android client - Use MSCHAPv2
I am having issues getting EAP-MSCHAPv2 working with the Android client. The feature list explicitly states that the android client supports EAP-MSCHAPv2, but I see no way to actually enforce that on the client, and the authentication keeps failing because EAP-MD5 is used.
Re: [strongSwan] KEY_ID encoding
Hi Volodymyr, > do not work - StrongSwan do not consider this connection when choosing > between few. Increase the log level for cfg to 3 [1] to see details about the matched identities and read or send the log. > What is the right way to describe id for PSK connection where remote > part uses key-id type, e.g. on Cisco it is "crypto isakmp identity > key-id aa"? Don't know what Cisco will send if you do that, so no idea. You'll see that in the log. > And which id need to be used in 'secrets' section to achieve the result? > Should it be It must match the identity value and type you configure in the remote section. Regards, Tobias [1] https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration
