Hi,
Cannot make it run using password authentication.
Here is the configuration that worked:
1. Created 3 certs - one for remote, one for local and user authentication certificate
2. VPN definition:
Type: IKE 1
Mode: Dynamic IP restricted client
Burb: internal
Enc: Tunnel
Local: Use Localhost IP
Remote Authentication - Remote certificate
Local Authentication - Local Certificate
Enable NAT Traversal
Mode Aggressive
And that's it - on the other side, I used VPN Tracker 8 with cerificates imported. And it worked.
Now, I tried to setup that VPN password based and hit the wall.
I tried different configurations - IKE1/Aggressive, IKE2/Main, IKE2/XAUTH. Always, I'm getting error that the connection was dropped due to policy.
In remote tab, I have password and remote identity - ID Kal, DN "sname" and mail address, In local tab I have grayed out password and IP Address "localhost"
I try both VPN Tracker and recommended shrew on Windows. With certs it works, with password it does not....
Please help - any advise really apreciated!
Kal
I checked the audit:
exchange mode (AGGRESSIVE MODE) not supported by policy, packet dropped
Solved! Go to Solution.
The first thing you should do is upgrade this firewall to 70103H10, so that the 1500+ bug fixes between 70102 and 70103H10 can be discounted as the problem (although I do not see any bugs here, per se, just perhaps a misconfiguration). You have a 7-day license when you install version 7 in which to install patches when you have no licensed Support.
The firewall is using the Public IP your VPN-client is going through (some router at the edge of that network) as the Remote Network in the VPN Definition. When you have a "Dynamic IP Client" VPN Definition you can see the Remote IP is greyed-out and says 'client' and the Remote Network IP is greyed-out (so you cannot change these). Your VPN Client (VPN Tracker I take it) is sending its local, private IP address as the Remote Network instead. The client does not, presumably, have any way to know what's its Public IP address is so it cannot send that as the Remote Network to the firewall.
Try this small change:
Change the VPN Mode to "Dynamic IP Restricted Client." Leave the "Client address pool" setting as <disabled> and then click New under the Remote Network IP section and add 192.168.0.10/32...
Wait...
Your client IP address is in the same network as the Local Network that is behind the firewall so this setup will not work, even if the tunnel came up. I should have seen that sooner. Your client PC and any clients behind the firewall are simply going to ARP for any addresses in 192.168.0.0/24 (to which 192.168.0.10 belongs). The ARPs are broadcast only on your local network, they will not go over the VPN. If you were to get this VPN established and you tried to connect from the client to an IP across the tunnel your client will simply send ARPs on its local network, get no response, and then stop trying.
What you should do is set up Client Address Pools on the firewall. These are pushed to VPN Clients via the Mode Config process of ISAKMP. This way you assign incoming VPN clients an IP address from a specific-pool of IPs so that, just as you see here, if their local private IP (from a coffee shop let's say) happens to be in the same network as your local firewall network they can still connect. There are two different scenarios like this detailed in the 70103 Admin Guide and in various knowledgebase articles.
The one error you pasted simply means you had Main Mode selected on the firewall side and Aggressive Mode selected on the client for that attempt. Provided you make those match for the next attempt and it doesn't work, is there a different error in the audit? You also need to troubleshoot from the client side. If you ever see 'Retransmitting...' in a VPN-audit you know that the client has an error and has stopped responding to the firewall (therefore you must troubleshoot on the client side).
If you can, I suggest calling in to Support to troubleshoot this with a remote session.
Thanks a lot, but I'm afraid it is not that case. Unfortunately, I cannot raise the ticket yet - we have a pair of aftermarket devices with 7.0.1.02 SecureOS, and currently we are evaluating if they will suit our needs, if so, we will obtain support for sure, but till that moment, we have to rely on community help
So, I gathered some logs, first policy summary:
ipsec add name=ike_1_password type=password encapsulation=tunnel active=0 \
authalgorithm=sha1,md5 burb=internal encryptalgorithm=cast128,3des,des \
fw-id=FQDN:sky.com fwauthmethod=password fwgw=localhost ids=Kal \
ippoolid=All options=NO_STRICT_ID_MATCHING,NAT_T,INITIAL_CONTACT \
p1auth=sha1,md5 p1crypt=aes256,aes128,3des,des p1exchange=AGGRESSIVE_MODE \
p1life-kb=0 p1life-sec=3600 p1oakly=5,2,1 p1soft=85 p2life-kb=0 \
p2life-sec=700 p2soft=85 password='*' pfs=0 position=3 remotegw=dynamic \
srcnet='' version=1
and log from client side:
18:11:55 VPN Connection Requested
18:11:55 Action on error is now stop
18:11:55 This is VPN Tracker 8.1 cc3538137be2
18:11:55 Preparing Connection
18:11:58 Next step: Removing reachability check for VPN gateway
18:11:58 Local network identifier is NETWORK-SIGNATURE://Modem.RemoteAddress=*99#
18:11:58 Checking for network collisions
18:11:58 Next step: Welcoming connectiond on socket 8
18:11:58 Next step: Updating connectiond process info
18:11:58 Configuring
18:11:58 call pfkey_send_register for AH (349)
18:11:58 call pfkey_send_register for ESP (349)
18:11:58 call pfkey_send_register for IPCOMP (349)
18:11:58 Next step: Sending connectiond config
18:11:58 Saving cached local endpoint 164.126.135.53
18:11:59 Phase 1 Started
18:11:59 Next step: Processing connectiond connection request
18:11:59 Next step: Starting Phase 1
18:11:59 Next step: Starting connectiond timeout
18:11:59 initiate new phase 1 negotiation: 164.126.135.53[51209]<=>46.186.89.252[500] (1049)
18:11:59 begin Aggressive mode. (1054)
18:11:59 === Phase 1 aggressive exchange / initiator / send 1 (106)
18:11:59 new cookie: 0f769bd8787c561b (2159)
18:11:59 local ID: Kal (KEY_ID) (3823)
18:11:59 created transform #1 len=36 (2836)
18:11:59 type=Life Type, flag=0x8000, lorv=seconds (1) (2203)
18:11:59 type=Life Duration, flag=0x8000, lorv=28800 (28800) (2203)
18:11:59 type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC (7) (2203)
18:11:59 type=Key Length, flag=0x8000, lorv=256 (256) (2203)
18:11:59 type=Authentication Method, flag=0x8000, lorv=pre-shared key (1) (2203)
18:11:59 type=Hash Algorithm, flag=0x8000, lorv=SHA (2) (2203)
18:11:59 type=Group Description, flag=0x8000, lorv=1024-bit MODP group (2) (2203)
18:11:59 created transform #2 len=36 (2836)
18:11:59 type=Life Type, flag=0x8000, lorv=seconds (1) (2203)
18:11:59 type=Life Duration, flag=0x8000, lorv=28800 (28800) (2203)
18:11:59 type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC (7) (2203)
18:11:59 type=Key Length, flag=0x8000, lorv=192 (192) (2203)
18:11:59 type=Authentication Method, flag=0x8000, lorv=pre-shared key (1) (2203)
18:11:59 type=Hash Algorithm, flag=0x8000, lorv=SHA (2) (2203)
18:11:59 type=Group Description, flag=0x8000, lorv=1024-bit MODP group (2) (2203)
18:11:59 created transform #3 len=36 (2836)
18:11:59 type=Life Type, flag=0x8000, lorv=seconds (1) (2203)
18:11:59 type=Life Duration, flag=0x8000, lorv=28800 (28800) (2203)
18:11:59 type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC (7) (2203)
18:11:59 type=Key Length, flag=0x8000, lorv=128 (128) (2203)
18:11:59 type=Authentication Method, flag=0x8000, lorv=pre-shared key (1) (2203)
18:11:59 type=Hash Algorithm, flag=0x8000, lorv=SHA (2) (2203)
18:11:59 type=Group Description, flag=0x8000, lorv=1024-bit MODP group (2) (2203)
18:11:59 created transform #4 len=32 (2836)
18:11:59 type=Life Type, flag=0x8000, lorv=seconds (1) (2203)
18:11:59 type=Life Duration, flag=0x8000, lorv=28800 (28800) (2203)
18:11:59 type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC (5) (2203)
18:11:59 type=Authentication Method, flag=0x8000, lorv=pre-shared key (1) (2203)
18:11:59 type=Hash Algorithm, flag=0x8000, lorv=SHA (2) (2203)
18:11:59 type=Group Description, flag=0x8000, lorv=1024-bit MODP group (2) (2203)
18:11:59 created transform #5 len=32 (2836)
18:11:59 type=Life Type, flag=0x8000, lorv=seconds (1) (2203)
18:11:59 type=Life Duration, flag=0x8000, lorv=28800 (28800) (2203)
18:11:59 type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC (1) (2203)
18:11:59 type=Authentication Method, flag=0x8000, lorv=pre-shared key (1) (2203)
18:11:59 type=Hash Algorithm, flag=0x8000, lorv=SHA (2) (2203)
18:11:59 type=Group Description, flag=0x8000, lorv=1024-bit MODP group (2) (2203)
18:11:59 created proposal #1 len=180 (2857)
18:11:59 add payload of len 188, next type sa (2289)
18:11:59 add payload of len 128, next type ke (2289)
18:11:59 add payload of len 16, next type nonce (2289)
18:11:59 add payload of len 7, next type id (2289)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-00 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-01 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-02 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-02\n (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-03 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-04 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-05 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-06 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-07 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: draft-ietf-ipsec-nat-t-ike-08 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: RFC 3947 (2311)
18:11:59 add payload of len 16, next type vid (2289)
18:11:59 added vendor id is: Dead Peer Detection (2311)
18:11:59 send phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:04 resend phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:09 resend phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:14 resend phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:19 resend phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:24 resend phase1 packet from 164.126.135.53[51209] to 46.186.89.252[500] (0f769bd8787c561b:0000000000000000) (1584)
18:12:29 phase1 negotiation with 46.186.89.252[500] failed (0f769bd8787c561b:0000000000000000) (1553)
18:12:29 VPN Gateway Not Responding (Phase 1)
and audit log:
Feb 26 12:11:14 2015 EST f_isakmp_daemon a_vpn t_debug p_minor
pid: 5616 ruid: 0 euid: 0 pgid: 5616 logid: 0 cmd: 'ikmpd'
domain: ikpd edomain: ikpd hostname: sky_fw_1.sky
information: ##### - in udp_read
Feb 26 12:11:14 2015 EST f_isakmp_daemon a_vpn t_debug p_minor
pid: 5616 ruid: 0 euid: 0 pgid: 5616 logid: 0 cmd: 'ikmpd'
domain: ikpd edomain: ikpd hostname: sky_fw_1.sky
information: ##### - in exchange_error
Feb 26 12:11:14 2015 EST f_isakmp_daemon a_vpn t_debug p_minor
pid: 5616 ruid: 0 euid: 0 pgid: 5616 logid: 0 cmd: 'ikmpd'
domain: ikpd edomain: ikpd hostname: sky_fw_1.sky
information: ##### - in process_error_queue
Feb 26 12:11:14 2015 EST f_isakmp_daemon a_vpn t_error p_major
pid: 5616 ruid: 0 euid: 0 pgid: 5616 logid: 0 cmd: 'ikmpd'
domain: ikpd edomain: ikpd hostname: sky_fw_1.sky cky_i: 0f769bd8787c561b
cky_r: 0000000000000000 local_gw: 46.186.89.252 remote_gw: 164.126.135.53
information: [detailed info]
[error]
AGGRESSIVE_MODE exchange processing failed
[error]
Received exchange type (AGGRESSIVE_MODE) not supported by policy, packet dropped
When I switch to MAIN on the client side, I got:
Feb 26 12:12:17 2015 EST f_isakmp_daemon a_vpn t_error p_major
pid: 5616 ruid: 0 euid: 0 pgid: 5616 logid: 0 cmd: 'ikmpd'
domain: ikpd edomain: ikpd hostname: sky_fw_1.sky cky_i: 38c722f334e76116
cky_r: 0000000000000000 local_gw: 46.186.89.252 remote_gw: 164.126.135.53
information: [detailed info]
[error]
MAIN_MODE exchange processing failed
[error]
Received exchange type (MAIN_MODE) not supported by policy, packet dropped
Hi, Absolutely no chance to get any support on above?
Regards
Kal
This VPN is not enabled.
Actually not.
I've just pasted wrong VPN definition, but the one that was enabled that moment was identical - I cloned the rule with different name - hoping that would help...
But there is more - today, I've reinstalled that device - run fresh SecureOS image from the pendrive, and did not restore any configuration. What I did after an initial setup (to keep simple - 2 burbs - one internal with one PC connected and one external to the internet):
1. Set up DNS
2. Checked connectivity - ping external address both from firewall and internal PC using host name
3. Defined rule enabling VPN (isamk from Any burb to Any)
4. Defined VPN rule with PSK
5. Defined VPN connection (from the scratch)
Checked and... EXACTLY THE SAME!!! Logs from the client shows that VPN gateway is not responding and Audit on Firewall showing
Received exchange type (AGGRESSIVE_MODE) not supported by policy, packet dropped
It seems clearly to me, that my firewall with 7.0.1.02 software has a bug. Browsing that forum, I found exactly the same case two years ago, but no solution as well...
EDIT - When I save the policy, I see the warning, that IKA 1 with password authentication is not secure, but it was only the warning. I cannot set up IKA 2 with password in aggressive mode, that's why it is the only option...
Kal
I do not see any bugs in our bug-database about this type of issue. If you'd like to upgrade this firewall to the latest version-7 code release (70103H10) you can download and install these two files:
ftp://downloads.securecomputing.com/packages/firewall/7.0.1/70103
ftp://downloads.securecomputing.com/packages/firewall/7.0.1/70103H10
This is how I'd do it on the firewall command-line:
$> cd /var/spool
(The /var/spool partition is large and mostly-unused, so it's where I download patches to when I'm patching a firewall.)
$> ftp ftp://downloads.securecomputing.com/packages/firewall/7.0.1/70103 .
$> ftp ftp://downloads.securecomputing.com/packages/firewall/7.0.1/70103H10 .
(Notice the [space][period] at the end, which means "Download this file and place it here in this current-directory with the same name.")
-- Load the packages
$> cf pack load source=file directory=/var/spool packages=70103,70103H10
-- Install the packages
$> cf pack install pack=70103,70103H10
Once the firewall reboots, try the VPN connection again.
BEFORE that, please paste the 'cf ipsec query' output you have right now. Also, run this command and paste the output here: 'cf cert q id'.
ipsec add name=vpn type=password encapsulation=tunnel active=1 \
authalgorithm=sha1,md5 burb=internal \
encryptalgorithm=aes256,aes128,cast128,3des,des fw-id=FQDN:skyfw1.sky.pl \
fwauthmethod=password fwgw=localhost ids=kkalukin \
options=NAT_T,INITIAL_CONTACT p1auth=sha1,md5 \
p1crypt=aes256,aes128,3des,des p1exchange=AGGRESSIVE_MODE p1life-kb=0 \
p1life-sec=3600 p1oakly=5,2,1 p1soft=85 p2life-kb=0 p2life-sec=700 \
p2soft=85 password='*' pfs=0 position=1 remotegw=client \
srcnet=192.168.0.0/24 version=1
cert add id name=kkalukin dn=kkalukin@sky.pl
The format of your 'id' is incorrect. Run this command to modify it:
$> cf cert modify id name=kkalukin dn=cn=kkalukin@sky.pl
(You're adding 'cn=' to the id; you can do this in the GUI also, add the cn= part to the front of that string.)
Restart isakmp:
$> cf daemond restart agent=isakmp
Now try the VPN again.
WOW!
I'm getting somewhere, here is the log from my client:
21:22:40 Phase 2 Started
21:22:40 Next step: Processing connectiond connection request
21:22:40 Next step: Starting Phase 2
21:22:40 pfkey GETSPI sent: ESP/Tunnel 46.186.91.2-->172.20.10.2 (192.168.0.10/32<-->192.168.0.0/24) (774)
21:22:40 pfkey GETSPI message (196)
21:22:40 pfkey GETSPI succeeded: ESP/Tunnel 46.186.91.2-->172.20.10.2 (192.168.0.10/32<-->192.168.0.0/24) spi=177516576(0xa94b020) (849)
21:22:40 === Phase 2 exchange / initiator / send 1 (151)
21:22:40 local ID: 192.168.0.10 (IPv4_address) (4071)
21:22:40 remote ID: 192.168.0.0 (IPv4_subnet) (4125)
21:22:40 add payload of len 172, next type: nonce (2336)
21:22:40 add payload of len 16, next type: id (2336)
21:22:40 add payload of len 8, next type: id (2336)
21:22:40 add payload of len 12, next type: none (2336)
21:22:40 phase 2, next type: hash (2257)
21:22:40 add payload of len 20, next type: sa (2336)
21:22:40 send phase2 packet to 46.186.91.2[4500] (8b33d31d585b7fb7:99cf75e0dc57c15e:0000b05d) (1643)
21:22:40 notification message 18:INVALID-ID-INFORMATION, doi=1 proto_id=3 spi=0a94b020(size=4). (1325)
21:22:40 Identifier Mismatch (Phase 2)
The VPN gateway notified VPN Tracker that the identifiers sent by VPN Tracker for Phase 2 do not match its own identifiers. Please do the following (or ask your administrator to do this):
• Compare the local address or network configured in VPN Tracker to the VPN gateway's remote address (or network) setting
• Compare the remote network(s) configured in VPN Tracker to the VPN gateway's local network(s)
Status: 0x90E05 (PHASE2_INVALID_ID_INFO)
21:22:40 Last error was at 0 and it is now 1425586960.
21:22:40 About to Disconnect (Error)
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA