IDir '10.20.30.40' does not match to '10.20.30.40' and how to get real identity types
-
Hello, I am troubleshooting IPsec tunnel which refuses to connect, and as far as I know it has to do with this line in IPsec log:
charon 13[IKE] <con2000|11> IDir '10.20.30.40' does not match to '10.20.30.40'IP is modified, but both strings (both IPs) are exactly the same. It is somewhat confusing to get error message telling me that "ABC123" is not equal to "ABC123".
I have found this (old) post which explained to me that, apart of strings, there is also "identity type" used as a part of exchange, so the IPs might be in fact the same, but one of them is probably different "identity type" then the other one (for example "KeyID tag" VS "IP address", containing same string).Is there any way for me how to see which IDs are used on local and remote side of attempted tunnel? In mentioned post there is proposed change in strongswan code, but that is unsuitable for me to make in pfSense's implementation.
-
What is in the configuration file for the ID?
You might be able to turn up the logging detail for IKE and it may print something more helpful there.
If you're using IKEv1 and aggressive mode you might be able to packet capture the IKE packets (udp/500) and have wireshark tell you the IDs and so on, but AFAIK that gets encrypted in IKEv2 and main mode. I know for sure it's encrypted in IKEv2 but I don't have an IKEv1 tunnel handy I can disconnect and capture to confirm the other case.
-
@jimp
Thank you for your answer and suggestions!What is in the configuration file for the ID?
Sorry, I don't understand, do you mean my pfSense configuration file? That contains same value as in GUI. I am more interested in knowing what identity type is used by remote side of connection (not pfSense and not controlled by me). The other side uses FortiGate and I was told it has only text field without identity type specification (unlike pfSense). I understand FortiGate might be doing things differently, I would just expect to get more helpful information from IPsec log on my side, why ID strings are not considered equal.
You might be able to turn up the logging detail for IKE and it may print something more helpful there.
I have tried to turn up logging details for "IKE SA" and "IKE Child SA" but haven't seen anything more helpful. But there are many logging components with 6 or so levels of logging for each of them, maybe it is somewhere, I haven't found it though.
If you're using IKEv1 and aggressive mode you might be able to packet capture the IKE packets (udp/500) and have wireshark tell you the IDs and so on, but AFAIK that gets encrypted in IKEv2 and main mode. I know for sure it's encrypted in IKEv2 but I don't have an IKEv1 tunnel handy I can disconnect and capture to confirm the other case.
I am using IKEv1 (remote side's decision) but it seems to me this part of negotiation is encrypted and I was unable to get encryption key from pfSense (my other question in this forum). And generally speaking - it seems a bit too involved to resort to Wireshark and IPsec decryption just to determine identity types.
-
Unfortunately it doesn't look like strongSwan will log the ID type. Not sure why, seems like it would be rather useful.
Since the fortigate is manually specifying an ID of an unknown type you might have better luck using a "Key ID" string or "User Distinguished Name" type. Put a custom string in the FortiGate side, like "fortigatevpn" and then put the same string on pfSense in the Peer identifier using one of the types I mentioned.
strongSwan will automatically use the type most appropriate for the given string in most cases, but if the far side is deliberately using the "wrong" type for values in that field, it might be difficult to force a match using a string which should be a specific (different) type.
