VPN Tunnel between two Cisco WRV210

Unanswered Question
Dec 9th, 2009

Hi, I'm trying to establish a tunnel between two Cisco WRV210 VPN routers.

They are set up like this:

   Router A - Internet - NAT-Router (unknown) - Router B

where Router A and B are the Cisco WRV210 models.
and where Router A has IP "Router_A_IP"


I set up Router A as follows:

tunnel name: pholm
nat traversal: enabled
Local secure group: subnet (IP: 192.168.1.0 / 255.255.255.0)
Remote secure group: Any
Remote secure gateway: Any
ISAKMP DH Group: (changed to 2048-bits)


Router B
tunnel name: pholm
nat traversal: disabled
local secure group: subnet (IP: 192.168.2.0 / 255.255.255.0)
remote secure group: Host
remove secure gateway: "Router_A_IP"
ISAKMP DH Group: (changed to 2048-bits)


and of course I added the same preshared key.



However I can't get the tunnel working. What's wrong?


I get this vpn log from Router B:

-----------------------------

                000   [Sat 05:54:01]  "TunnelA": deleting connection
001   [Sat 05:54:01]  "TunnelA" #3: deleting state (STATE_MAIN_I4)
002   [Sat 05:54:01]  packet from "Router_A_IP":4500: Informational Exchange is for an unknown (expired?) SA
003   [Sat 05:54:04]  added connection description "TunnelA"
004   [Sat 05:54:04]  "TunnelA" #9: initiating Main Mode
005   [Sat 05:54:04]  "TunnelA" #9: [WRV210 Response:] ISAKMP SA (Main Mode) Initiation
006   [Sat 05:54:04]  "TunnelA" #9: received Vendor ID payload [Openswan (this version) 2.4.5dr3  X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
007   [Sat 05:54:04]  "TunnelA" #9: received Vendor ID payload [Dead Peer Detection]
008   [Sat 05:54:04]  "TunnelA" #9: received Vendor ID payload [RFC 3947] method set to=109
009   [Sat 05:54:04]  "TunnelA" #9: enabling possible NAT-traversal with method 3
010   [Sat 05:54:04]  "TunnelA" #9: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
011   [Sat 05:54:04]  "TunnelA" #9: STATE_MAIN_I2: sent MI2, expecting MR2
012   [Sat 05:54:05]  "TunnelA" #9: I did not send a certificate because I do not have one.
013   [Sat 05:54:05]  "TunnelA" #9: WARNING: calc_dh_shared(): for OAKLEY_GROUP_MODP2048 took 250000 usec
014   [Sat 05:54:05]  "TunnelA" #9: NAT-Traversal: Result using 3: i am NATed
015   [Sat 05:54:05]  "TunnelA" #9: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
016   [Sat 05:54:05]  "TunnelA" #9: STATE_MAIN_I3: sent MI3, expecting MR3
017   [Sat 05:54:05]  "TunnelA" #9: Main mode peer ID is ID_IPV4_ADDR: 'Router_A_IP'
018   [Sat 05:54:05]  "TunnelA" #9: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
019   [Sat 05:54:05]  "TunnelA" #9: [WRV210 Response:] ISAKMP SA established
020   [Sat 05:54:05]  "TunnelA" #9: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp2048}
021   [Sat 05:54:05]  "TunnelA" #9: Dead Peer Detection (RFC 3706): enabled
022   [Sat 05:54:05]  "TunnelA" #10: [WRV210 Response:] IPSec SA (Quick Mode) Initiation
023   [Sat 05:54:05]  "TunnelA" #10: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#9}
024   [Sat 05:54:05]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
025   [Sat 05:54:05]  "TunnelA" #9: received and ignored informational message
026   [Sat 05:54:15]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
027   [Sat 05:54:15]  "TunnelA" #9: received and ignored informational message
028   [Sat 05:54:35]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
029   [Sat 05:54:35]  "TunnelA" #9: received and ignored informational message
030   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
031   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
032   [Sat 05:55:15]  "TunnelA" #10: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
033   [Sat 05:55:15]  "TunnelA" #10: starting keying attempt 2 of at most 5, but releasing whack
034   [Sat 05:55:15]  "TunnelA" #11: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #10 {using isakmp#9}
035   [Sat 05:55:15]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
036   [Sat 05:55:15]  "TunnelA" #9: received and ignored informational message
037   [Sat 05:55:16]  forgetting secrets
038   [Sat 05:55:16]  loading secrets from "/etc/ipsec.secrets"
039   [Sat 05:55:25]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
040   [Sat 05:55:25]  "TunnelA" #9: received and ignored informational message
041   [Sat 05:55:45]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
042   [Sat 05:55:45]  "TunnelA" #9: received and ignored informational message
043   [Sat 05:56:25]  "TunnelA" #11: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
044   [Sat 05:56:25]  "TunnelA" #11: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
045   [Sat 05:56:25]  "TunnelA" #11: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
046   [Sat 05:56:25]  "TunnelA" #11: starting keying attempt 3 of at most 5
047   [Sat 05:56:25]  "TunnelA" #12: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #11 {using isakmp#9}
048   [Sat 05:56:25]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
049   [Sat 05:56:25]  "TunnelA" #9: received and ignored informational message
050   [Sat 05:56:25]  forgetting secrets
051   [Sat 05:56:25]  loading secrets from "/etc/ipsec.secrets"
052   [Sat 05:56:35]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
053   [Sat 05:56:35]  "TunnelA" #9: received and ignored informational message
054   [Sat 05:56:55]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
055   [Sat 05:56:55]  "TunnelA" #9: received and ignored informational message
056   [Sat 05:57:35]  "TunnelA" #12: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
057   [Sat 05:57:35]  "TunnelA" #12: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
058   [Sat 05:57:35]  "TunnelA" #12: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
059   [Sat 05:57:35]  "TunnelA" #12: starting keying attempt 4 of at most 5
060   [Sat 05:57:35]  "TunnelA" #13: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #12 {using isakmp#9}
061   [Sat 05:57:35]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
062   [Sat 05:57:35]  "TunnelA" #9: received and ignored informational message
063   [Sat 05:57:35]  forgetting secrets
064   [Sat 05:57:35]  loading secrets from "/etc/ipsec.secrets"
065   [Sat 05:57:45]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
066   [Sat 05:57:45]  "TunnelA" #9: received and ignored informational message
067   [Sat 05:58:05]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
068   [Sat 05:58:05]  "TunnelA" #9: received and ignored informational message
069   [Sat 05:58:45]  "TunnelA" #13: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
070   [Sat 05:58:45]  "TunnelA" #13: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
071   [Sat 05:58:45]  "TunnelA" #13: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
072   [Sat 05:58:45]  "TunnelA" #13: starting keying attempt 5 of at most 5
073   [Sat 05:58:45]  "TunnelA" #14: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #13 {using isakmp#9}
074   [Sat 05:58:45]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
075   [Sat 05:58:45]  "TunnelA" #9: received and ignored informational message
076   [Sat 05:58:46]  forgetting secrets
077   [Sat 05:58:46]  loading secrets from "/etc/ipsec.secrets"
078   [Sat 05:58:55]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
079   [Sat 05:58:55]  "TunnelA" #9: received and ignored informational message
080   [Sat 05:59:15]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
081   [Sat 05:59:15]  "TunnelA" #9: received and ignored informational message
082   [Sat 05:59:55]  "TunnelA" #14: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
083   [Sat 05:59:55]  "TunnelA" #14: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
084   [Sat 05:59:55]  "TunnelA" #14: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
085   [Sat 05:59:55]  forgetting secrets
086   [Sat 05:59:55]  loading secrets from "/etc/ipsec.secrets"

-----------------------------




and this "Advanced tunnel information":

-----------------------------
000 "TunnelA":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
000 "TunnelA":   ike_life: 28800s; ipsec_life: 3600s; rekey_margin: 60s; rekey_fuzz: 100%; keyingtries: 5
000 "TunnelA":   policy: PSK+ENCRYPT+TUNNEL+UP; prio: 24,32; interface: eth0;
000 "TunnelA":   dpd: action:restart; delay:30; timeout:120;
000 "TunnelA":   newest ISAKMP SA: #9; newest IPsec SA: #0;
000 "TunnelA":   IKE algorithms wanted: 5_000-1-14, flags=-strict
000 "TunnelA":   IKE algorithms found:  5_192-1_096-14,
000 "TunnelA":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP2048
000 "TunnelA":   ESP algorithms wanted: 3_000-1, flags=-strict
000 "TunnelA":   ESP algorithms loaded: 3_000-1, flags=-strict
000 #9: "TunnelA":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 27701s; newest ISAKMP; lastdpd=1001s(seq in:10613 out:0)
-----------------------------



Best regards,

Preben Holm

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bethingt Wed, 12/09/2009 - 12:21

I would recommend change the groups and gateway from any to IP or subnet. Also what firmware are you useing?

Brian

Gerald Vogt Wed, 12/09/2009 - 15:10

The reason why it does not work is right there in the log:

030   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
031   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.

The local and remote security groups do not match on both ends. ("are asymmetric").

On one end you have:

Local secure group: subnet (IP: 192.168.1.0 / 255.255.255.0)
Remote secure group: Any

On the other end you have:

local secure group: subnet (IP: 192.168.2.0 / 255.255.255.0)
remote secure group: Host

That does not match. Local and remote security groups must match to negotiate the tunnel. These two policies will never work together. Change it to matching policies, e.g.:

local 192.168.1.0/255.255.255.0

remote 192.168.2.0/255.255.255.0

and vice versa on the other end.

It's essential that the groups match. The IPSec tunnel will only encrypt and tunnel IP packets which have the local group as source IP and the remote group as destination IP. The IPSec tunnel will only accept and decrypt IP packets which have the remote group as source IP and the local group as destination IP.

Alejandro Gallego Thu, 12/10/2009 - 00:10

Really the problem is a lot simpler, while gerald is correct we have a mismatch in our addressing but it is not because of how you applied the settings. It starts before you even enabled the tunnel.

Topology:

Router A >> IPSec >> "NAT" Rtr >>> Router B

Because you have a NAT router the other end of tunnel, router A can't hit it directly; we get NAT'ed. So when (B) responds router A actually gets its actual IP address which is different so the tunnel fails. In other words is like this:

RtrA wants to connect to public IP 12.12.x.x and says "I have local network 192.168.1.0 and I want to connect to you".

RtrB responds and says "awesome, i can accept "ANY" public and "ANY" private, lets do it"

So RtrB send back its information; but since the poor fellow is NAT'ed he sends his PRIVATE IP address and his double NAT'd LAN IP. So when RtrA recieves this message he's thrown for a loop.

RtrA says "I wanted to connect to 12.12.x.x, but this guy with 192.168.2.1 just told me to start my tunnel...! This doesn't match my security groups so sorry 192.168.2.1, I will not connect to you".

Rtr A, and B; must have a Public IP. If they do not it will be very difficult to get a stable tunnel. It is possible depending on the equipment and if we can manage it. Talk with your ISP and see if you can get that NAT router into bridge or passthrough mode (kinda assuming it is a modem here).

Let us know if you more questions.

prebenhsh Thu, 12/10/2009 - 00:28

Hi,

I just got it working by using the second answer - Thanks.

However for the Cisco representative: I enabled the NAT traversal for router A and accepted "Any IP" as remote host to connect to the router - exactly to get the NAT working (it's not possible to set an IP when NAT is enabled). And second - the remote security gateway is set to the IP of router A - which means, that Router A is accepting the nat'ed router B's connection (Router B is the initiating part).

Best regards

Preben Holm

Gerald Vogt Thu, 12/10/2009 - 00:46

alegalle, the log shows that ISAKMP negotiation already works. It says: "ISAKMP SA established". This means that port forwarding or strict NAT has already been set up on the NAT router. Both routers are able to talk to each other.

As far as I know, for IPSec the local and remote security group on both ends must match - in the sense of be identical except for swapping local and remote. Router A cannot say I have local security group 192.168.1.0/255.255.255.0 while router B says I accept remote security group ANY. This does not match in IPSec. ANY means 0.0.0.0/0.0.0.0 and only matches 0.0.0.0/0.0.0.0.

Therefore, I think the "awsome" response RtrB will never be because IPSec policies are not matched this way. It must be identical not inclusive. This is because in reality the underlying IPSec implemention of policies will create a set of two policies for the connection: one for A-to-B and one for B-to-A.

Regarding the gateway addresses settings don't have to match but reflect the IP addresses as seen on either end.

Router A: local gateway address is public IP address of A. Remote gateway address is the public IP address of NAT router.

Router B: local gateway address is WAN IP address of B (i.e. the private IP address behind NAT router). Remote gateway address is public IP address of router A.

These are the IP addresses actually seen on either end. Of course, IPSec and NAT don't go so well. As NAT traversal is required here I guess it may be necessary to accept any remote gateway address on router B because the public IP address of router A does not work. But I am not so much into the details of how NAT traversal works for IPSec exactly. I try to avoid NAT traversal under all circumstances...

Alejandro Gallego Thu, 12/10/2009 - 05:28

Glad to hear it all worked out in the end. I guess I may have misunderstood what was happenning or how the tunnel was being created. I don't see how we can say that the tunnel was established and stable when it is constatntly renegotiating:

014   [Sat 05:54:05]  "TunnelA" #9: NAT-Traversal: Result using 3: i am NATed
015   [Sat 05:54:05]  "TunnelA" #9: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
016   [Sat 05:54:05]  "TunnelA" #9: STATE_MAIN_I3: sent MI3, expecting MR3
017   [Sat 05:54:05]  "TunnelA" #9: Main mode peer ID is ID_IPV4_ADDR: 'Router_A_IP'
018   [Sat 05:54:05]  "TunnelA" #9: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
019   [Sat 05:54:05]  "TunnelA" #9: [WRV210 Response:] ISAKMP SA established
020   [Sat 05:54:05]  "TunnelA" #9: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp2048}
021   [Sat 05:54:05]  "TunnelA" #9: Dead Peer Detection (RFC 3706): enabled
022   [Sat 05:54:05]  "TunnelA" #10: [WRV210 Response:] IPSec SA (Quick Mode) Initiation
023   [Sat 05:54:05]  "TunnelA" #10: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#9}
024   [Sat 05:54:05]  "TunnelA" #9: ignoring informational payload, type INVALID_ID_INFORMATION
025   [Sat 05:54:05]  "TunnelA" #9: received and ignored informational message
026   [Sat 05:54:15]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
027   [Sat 05:54:15]  "TunnelA" #9: received and ignored informational message
028   [Sat 05:54:35]  "TunnelA" #9: ignoring informational payload, type INVALID_MESSAGE_ID
029   [Sat 05:54:35]  "TunnelA" #9: received and ignored informational message
030   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Can't establish IPSec SA. This might be the asymmetric Secure Group setting.
031   [Sat 05:55:15]  "TunnelA" #10: [WRV210 Response:] Please check your Local Secure Group, Remote Secure Group, and PFS setting of this tunnel.
032   [Sat 05:55:15]  "TunnelA" #10: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
033   [Sat 05:55:15]  "TunnelA" #10: starting keying attempt 2 of at most 5, but releasing whack
034   [Sat 05:55:15]  "TunnelA" #11: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #10 {using isakmp#9}

In the above we see "SA established" then one second later it SA is not valid and the tunnel disconnects. This pattern is repeated again, that tunnel is not established or stable.

Screen shot 2009-12-10 at 8.15.27 AM.png

This was my undestanding of the original set up. By specifying this we are creating a "Client to Gateway" tunnel, which indeed is valid. If this router is the NAT'ed router we would see a similar log as what is posted. If I set my router to connect to this one, and I specify the public IP (which would really be the NAT router) and the local security as the LAN of the above router, we most likely not connect.

Either way the point is that the tunnel is established, and it all worked out in the end. I apologize if I caused more confusion than neccessary.

Actions

This Discussion