Troubleshooting Tip: Diagnosing IPsec error 'failed to create dialup instance, error 22: Invalid argument'
| Description | This article describes some possible causes for the error message 'failed to create dialup instance, error 22: Invalid argument' that can appear when checking iked debug output.
In these scenarios, administrators may find that the VPN tunnel (or ADVPN shortcut tunnels) are failing to establish despite functioning network connectivity between the FortiGate and the VPN peer. |
| Scope | FortiGate, Dialup IPsec |
| Solution | This issue is currently known to occur in two separate scenarios, both of which involve a dial-up IPsec configuration with FortiGates as both the hub and the spoke(s):
Scenario 1: Dial-up IPsec tunnel fails to establish on the hub FortiGate due to location-id setting On the hub FortiGate, VPN traffic is being sent/received to spokes over the WAN connection successfully, but the VPN tunnel is failing to establish. When the iked debugs are checked, the following is observed on the hub FortiGate:
FortiGate_Hub # diagnose debug iked -1 Debug messages will be on for 30 minutes.
FortiGate # diagnose debug enable [...] ike 0:EDGE_INET1_c4: tunnel created tun_id 10.15.54.118/::10.14.82.54 remote_location 10.255.208.231 [...]
This problem occurs on older firmware if a location-id is configured on the spoke FortiGates and SD-WAN is configured on the hub FortiGate. To confirm if this is the case, check the spoke FortiGate configuration under config system settings:
config system settings set h323-direct-model enable set gui-dynamic-routing enable set location-id 10.255.208.231 <--- location-id is configured at the spoke. end
This issue is fixed by Change #954614 as of FortiOS v7.0.13, v7.2.9, v7.4.2, and all later versions. If an immediate firmware upgrade is not possible, then a workaround is to unset/disable the location-id setting on any spoke devices that cannot establish a tunnel to the hub FortiGate, as this is the direct trigger for the issue.
Scenario 2: Dial-up IPsec tunnel fails to establish on the hub or spoke FortiGate that has net-device enabled This scenario can only occur on FortiGates that have net-device enable configured on the IPsec VPN, and even then, it is rarely and randomly triggered. Generally speaking, ADVPN hubs will not experience this issue (since the recommendation is to use net-device disable), but spokes may encounter this issue since net-device enable is required for SD-WAN functionality.
When the issue occurs, the following may be repeatedly observed in IKed debugs when the spoke FortiGate is attempting (and failing) to establish a shortcut tunnel to another spoke:
FortiGate_Hub # diagnose debug iked -1 Debug messages will be on for 30 minutes.
FortiGate # diagnose debug enable [...] ike 0:advpn1: adding new dynamic tunnel for 192.0.2.90:0 ike 0:advpn1_0: tunnel created tun_id 10.255.254.5/::192.168.59.50 remote_location 0.0.0.0 [...]
The reason this issue occurs is that net-device enable results in the FortiGate creating IPsec interfaces in the underlying kernel for each dial-up connection made (including shortcut tunnels). FortiOS can generally add/remove these kernel interfaces without issue, but sometimes the kernel interfaces are not removed when the associated tunnel goes down. When the tunnel is reconnected, it conflicts with this kernel interface and is unable to be established successfully.
This issue is resolved when FortiOS v7.6.4 was tested, so consider upgrading to this version or later if this is a frequent issue (though generally the issue should occur rarely). The only workaround currently available if this occurs is to reboot the FortiGate, as this will clear any existing kernel interfaces and resolve the conflict. |