[Problem] VPN zwischen Fritz und StrongSwan Ike Error 0x2005?

There's more than one possible problem.

First suggestion: Even if it's a good idea to obfuscate the real configuration ... your editings to the configuration and log files render them useless, because no one can see possible format errors anymore. If you have post some of them later again, try to substitute the real values with more readable replacements preserving the structure. The value "[email protected]" looks like an IP address and a domain name, "%IP@something%" is gibberish (I'd assume, IP is "257.10.11.987", is this correct ?).

Reading your StrongSwan log file I get the impression, that your FRITZ!Box is using a dynamic address and your StrongSwan installation is unable to locate the correct pre-shared key in main mode. Try to use aggressive mode, if the originator is using a dynamic IP address.

You have to initiate the IPSec connection from the dynamic address in this case and it looks like your StrongSwan installation is unable to find the right key, because in main mode only the originating IP address (or a certificate, but that's not supported by AVM's firmware) can be used as a key to find the correct PSK value. In aggressive mode this information is submitted within the first packet and the key may be found. I'm using another IPSec implementation, therefore I'm unsure, if StrongSwan can accept aggressive mode as responder ... but afaik, there's a good manual, which should answer the question.

An additional pitfall could be the difference between "native" IPSec and "NAT traversal". If your Ubuntu system is not using a public IP address (that means, it is not connected to the internet directly), set your StrongSwan installation to "mandatory NAT-T mode". The final result is the limitation to a single UDP port (4500) for the whole IPSec traffic. The last line of your StrongSwan log shows, that the two systems try to communicate over UDP port 500, which would require an additional ESP channel (proto 50) and can render some additional problems in a scenario, where the Ubuntu system is located behind a (NAT) router.

The third question is, if it's possible to merged phase1 authentications (ipaddr on one and fqdn on the other side). These settings aren't real "addresses", the values are used as lookup keys to find the correct settings on each side and there's no reason to mix them up like you did. Here I'm unsure, if it's possible ... but I would not try it as first attempt.

And last, but not least ... why is your "left subnet" not really set ? First you should try to install a working connection and later you can expand it to suit your needs.

Your intention looks a little bit curious ... first you install a left subnet of 0/0 and later you try to limit the access over the IPSec tunnel to a single host (10.177.177.2) ? Publishing configuration and log files is a good decision ... but writing some lines of "context" (the idea, you want to realize) and to minimize the "masquerading" of real settings within the config and log files would be an even better one.

@ yngve0

First of all try to downgrade your 7390 to an Firmware < 6.20. Many people have a problem with IPSec since Firmware 6.20.
I have a lot of boxes as lan2lan client against different draytek routers. With 6.20 and 6.23 FW on 7490 it stops to work without
any changes in vpn config settings. Until now I could not find the reason for that.

Regards
sulihari

yngve0 schrieb:

My I ask which?

Zum Vergrößern anklicken....

I'm using racoon on openSuSE installations ... but I have real (dedicated) servers.

StrongSwan does accept aggressive mode but it is not recommended together with PSK and require that i override some security-settings in the global config.

Zum Vergrößern anklicken....

You should read some writings 'bout the difference between the possible modes. It's not impossible to use main mode with one dynamic endpoint, but it's not as easy and requires some additional actions, if the dynamic address is changed (reloading the IPSec configuration after the address has changed is one possible solution, but you've to inform the server that it's needed).

In main mode the identity of the remote endpoint is supplied within a secured context and there has to be another way to select the proper keys before the identity is known. If you use certificates, they will provide this identity and even a fixed IP address can be used as such a selector. But if you don't know anything about an incoming IPSec connection request, you need an unencrypted (and therefore unsecure, that's why it's not recommended, but a good PSK value (32 characters randomly generated) should be sufficient for your security) way to identify the remote endpoint to select the appropriate PSK value for the new connection.

My suggestion for the first reading would be http://www.internet-computer-security.com/VPN-Guide/Aggressive-Mode.html and my recommendation is to track down the links to some other descriptions, if you're not familiar with IPSec terms.

Another suggestion I'd like to make is: Add the "forceencaps" statement to your StrongSwan configuration and try to establish your connection with "forced NAT traversal". Even if your endpoints are not hidden behind a NAT firewall, it's another way to encapsulate the secured traffic and make the resulting IPSec packets more robust against changes (necessary changes to ensure the proper routing) on their way to the remote side.

Reading your log file I would say, that your StrongSwan instance tries to establish the connection at its own ... I would set it to "responder only" mode, 'cause the vServer can't be sure to talk to the right host, if it uses the known dynamic host name and the address has changed meanwhile or the FRITZ!Box is down and the last known address is assigned to another customer yet.

VPS located in a providers datacenter.

Zum Vergrößern anklicken....

If it's a virtual server based in Parallels Virtuozzo or OpenVZ, it may be impossible to use an IPSec VPN, as long as some requirements aren't met. And it's possible too, that you've to load some additional plugins for StrongSwan, have a look at the StrongSwan wiki.

sulihari schrieb:

Many people have a problem with IPSec since Firmware 6.20.

Zum Vergrößern anklicken....

Please substantiate that finding ... I - personally - can't agree with it. And many people are >10 in my opinion (or at least the half of that count) and even only, if their installations were working hassle-free with prior versions.

My VPN connections from FRITZ!Box routers to racoon and between different FRITZ!Box router models (without I14Y problems between different firmware versions - because I had no time to update the international versions of 7390 devices until now, they're still running 06.06 while german devices are on 06.20 already and - for 7490 - on 06.23 too) are working as usual ... there's no problem yet.

And while you wrote

sulihari schrieb:

Until now I could not find the reason for that.

Zum Vergrößern anklicken....

... which efforts did you make already ?

@PeterPawn

I'm not alone with that problem. The behavior is already reported here in ippf and for instance here blog.webernetz.net. I have tried avm recover to get a clean environment and step by step firmware update from 6.03 to 6.05 to 6.20 to 6.23 it works until 6.05 and does not work anymore with 6.20 and 6.23
as example vpn.cfg and ike.log

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "test";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remotehostname = "test.dyn##.de";
localid {
fqdn = "#####@#####";
}
remoteid {
fqdn = "+++++@+++++";
}
mode = phase1_mode_aggressive;
phase1ss = "alt/aes-3des/sha";
keytype = connkeytype_pre_shared;
key = "secret";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-des|3des-all/ah-all/comp-no/pfs";
accesslist = "permit ip any 192.168.2.0 255.255.255.0";

ok, result with FW 6.05 on 7270 (same on 7490 with 6.03 and 6.05)

ike.log

2015-01-03 12:27:27 avmike:< add(appl=dsld,cname=test,localip=89.14.51.103, remoteip=255.255.255.255, p1ss=alt/aes-3des/sha, p2ss=esp-des|3des-all/ah-all/comp-no/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x1 tunnel no_xauth no_cfgmode no_nat_t no_certsrv_server_auth)
2015-01-03 12:27:27 avmike:new neighbour test:
2015-01-03 12:27:44 avmike:test: Warning: source changed from 0.0.0.0:500 to 93.220.245.93:500
2015-01-03 12:27:44 avmike:mainmode test: selected lifetime: 3600 sec(no notify)
2015-01-03 12:27:44 avmike:mainmode test: add SA 1
2015-01-03 12:27:44 avmike:test remote peer supported DPD
2015-01-03 12:27:44 avmike:test: sending embedded inital contact message (0,93.220.245.93,0.0.0.0)
2015-01-03 12:27:44 avmike:test: Phase 1 ready
2015-01-03 12:27:44 avmike:test: current=0.0.0.0 new=93.220.245.93
2015-01-03 12:27:44 avmike:test: no valid sa, reseting initialcontactdone flag
2015-01-03 12:27:44 avmike:test: sending initial contact message
2015-01-03 12:27:44 avmike:test: start waiting connections
2015-01-03 12:27:44 avmike:test: Phase 2 starting (start waiting)
2015-01-03 12:27:44 avmike:test: Phase 2 ready
2015-01-03 12:27:44 avmike:< cb_sa_created(name=test,id=1,...,flags=0x00002101)
2015-01-03 12:27:44 avmike:test: start waiting connections
2015-01-03 12:27:44 avmike:test: NO waiting connections

failed after update 7490 to 6.20/6.23

ike.log

2015-01-03 12:20:20 avmike:test: Warning: source changed from 0.0.0.0:500 to 93.220.245.93:500
2015-01-03 12:20:20 avmike:mainmode test: selected lifetime: 3600 sec(no notify)
2015-01-03 12:20:21 avmike:mainmode test: add SA 1
2015-01-03 12:20:21 avmike:test remote peer supported DPD
2015-01-03 12:20:21 avmike:test remote peer supported NAT-T RFC 3947
2015-01-03 12:20:21 avmike:test: sending embedded inital contact message (0,93.220.245.93,0.0.0.0)
2015-01-03 12:20:21 avmike:test: switching to NAT-T (Initiator)
2015-01-03 12:20:21 avmike:test: Phase 1 ready
2015-01-03 12:20:21 avmike:test: current=0.0.0.0 new=93.220.245.93:4500
2015-01-03 12:20:21 avmike:test: no valid sa, reseting initialcontactdone flag
2015-01-03 12:20:21 avmike:test: local is behind a nat
2015-01-03 12:20:21 avmike:test: sending initial contact message
2015-01-03 12:20:21 avmike:test: start waiting connections
2015-01-03 12:20:21 avmike:test: Phase 2 starting (start waiting)

the FB GUI shows timeout 2027. It seems that phase2 won't work as before.
Do you have any idea/hint for troubleshooting ?

thx
sulihari

sulihari schrieb:

Do you have any idea/hint for troubleshooting ?

Zum Vergrößern anklicken....

I would say, your problem is (at least partly) "home made". You use a non-default selection for phase1 and phase2 proposals.

The firmware (here I assume a 7490 model due to the mentioned version 06.23) contains a file (/etc/default.Fritz_Box_HW185/avm/ipsec.cfg), where the specified name strings will be "translated" to IPSec proposals. Up to version 06.05 there were the following entries for phase1 (section ike_strategien) and phase2 (section ipsec_strategien) - mixed up together here, look into your own file for further informations and distinction between P1 and P2:
Starting with version 06.20 this list was made a little bit leaner:
So your configuration will not find the specified settings any longer and you've to change it to something different to suit your needs again. The other possible way would be, to modify the ipsec.cfg file and re-add the missing settings. Here the modfs script could help you, if you do not want to build a complete image with Freetz for your purposes.

The same remarks are valid for phase2 settings too ... you should have a look at the valid settings from ipsec.cfg to change your settings appropriately.

@PeterPawn

Excellent, thank you for your help. it works.

Regards
sulihari