1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

VPN problem between WRV200 and Zyxel

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by thelinksysuser, Apr 2, 2007.

  1. thelinksysuser

    thelinksysuser LI Guru Member

    Hello,

    I ve a problem with making a tunnel between a WRV200 and a Zyxel Prestige 2602HW-61.

    I ve running 2 firmware versions on the WRV200 and i am now on 1.0.29.

    I setupped on bothsides 3des/md5, also i changed both to a AES configuration without results.

    The physical situation is: the Zyxel is connected with the wanport to the internet. The WRV is connected behind a NAT modem/router with VPN passthrough enabled and portforwarded setupped to the linksys. I ve tested a regular bordermanager VPNclient over the WRV200 -> NAT moder/router - >internet and the Bordermanangerclient can connect to my work, so the VPN packets arent modified.??

    In someway there is big miscommunication going on. I ve editted the public IP-adres in the logfile to a generic IP-number.

    Can someone tell me what's wrong with the configuration or maybe both routers aren't compatible??? Please let me know.

    000 Plutorun started on Sun Apr 1 18:23:50 EST 2007
    001 [Sun 18:23:51] Starting Pluto (Openswan Version 2.4.5dr3 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEr\134[u@aflB_)
    002 [Sun 18:23:51] Setting NAT-Traversal port-4500 floating to on
    003 [Sun 18:23:51] port floating activation criteria nat_t=1/port_fload=1
    004 [Sun 18:23:51] including NAT-Traversal patch (Version 0.6c)
    005 [Sun 18:23:51] ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
    006 [Sun 18:23:51] starting up 1 cryptographic helpers
    007 [Sun 18:23:51] started helper pid=343 (fd:5)
    008 [Sun 18:23:51] Using KLIPS IPsec interface code on 2.4.26-uc0
    009 [Sun 18:23:52] Changing to directory '/etc/ipsec.d/cacerts'
    010 [Sun 18:23:52] Changing to directory '/etc/ipsec.d/aacerts'
    011 [Sun 18:23:52] Changing to directory '/etc/ipsec.d/ocspcerts'
    012 [Sun 18:23:52] Changing to directory '/etc/ipsec.d/crls'
    013 [Sun 18:23:52] Warning: empty directory
    014 [Sun 18:24:04] added connection description "TunnelA"
    015 [Sun 18:24:05] listening for IKE messages
    016 [Sun 18:24:05] adding interface ipsec0/eth0 192.168.1.254:500
    017 [Sun 18:24:05] adding interface ipsec0/eth0 192.168.1.254:4500
    018 [Sun 18:24:05] loading secrets from "/etc/ipsec.secrets"
    019 [Sun 18:24:10] "TunnelA" #1: initiating Main Mode
    020 [Sun 18:24:10] "TunnelA" #1: [WRV200 Response:] ISAKMP SA (Main Mode) Initiation
    021 [Sun 18:24:10] packet from 123.123.123.123:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    022 [Sun 18:24:10] packet from 123.123.123.123:500: received and ignored informational message
    023 [Sun 18:24:20] packet from 123.123.123.123:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    024 [Sun 18:24:20] packet from 123.123.123.123:500: received and ignored informational message
    025 [Sun 18:24:40] packet from 123.123.123.123:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    026 [Sun 18:24:40] packet from 123.123.123.123:500: received and ignored informational message
    027 [Sun 18:25:20] "TunnelA" #1: [WRV200 Response:] Remote peer has no tunnel entry to correspond to this tunnel.
    028 [Sun 18:25:20] "TunnelA" #1: [WRV200 Response:] Please check your Remote Secure Gateway setting.
    029 [Sun 18:25:20] "TunnelA" #1: max number of retransmissions (2) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message
    030 [Sun 18:25:20] "TunnelA" #1: starting keying attempt 2 of at most 3
    031 [Sun 18:25:20] "TunnelA" #2: initiating Main Mode to replace #1
    032 [Sun 18:25:20] packet from 123.123.123.123:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    033 [Sun 18:25:20] packet from 123.123.123.123:500: received and ignored informational message
     
  2. ifican

    ifican Network Guru Member

    You are not getting past ike phase 1. So recheck all of your phase 1 settings on both devices they have to be the same, also re-input your key on both sides to make sure its the same. You see that they can see each other, they just refuse to talk because NO_PROPOSAL_CHOSEN. It also appears that the zyxel is the one with the issue, the wrv is reporting that the remote peer has no tunnel entry. Also look at the log on zyxel and see what it thinks in wrong. Your not to far off, they are talking they just cant agree on how to set of the tunnel (generally a minor setting issue).
     
  3. thelinksysuser

    thelinksysuser LI Guru Member

    ok, thanks for your answer, i shall check the setup on both sides again. I let you know about the results.
     
  4. csayers

    csayers LI Guru Member

    My experience between these two brands is good once you connect.

    Do not use AES, In my experience the WRV200 does not have the same AES strength as the Zyxel (there are 3 different levels). Switch back to 3DES/MD5 to avoid problems. If the Zyxel has a checkbox for multiple proposals, check it.

    Reboot the Linksys end and wait for it to come up then reboot Zyxel end and allow it to come up. Hopefully it will connect if not try the reverse.
     
  5. thelinksysuser

    thelinksysuser LI Guru Member

    I ve found the misconfiguration on the side of the zyxel. It was set on DH1 and the Linksys supports only DH2 or higher.

    After that the message i had was gone. But now i run in a other problem of "PAYLOAD_MALFORMED". I ve read the docs what it is telling me, and it tolds to recheck the Preshared Key. I ve done so, several try's but none of the keys work. Now i ve put the key for example 0011223344556677889911 to make it simple but no results.

    Also i ve rebooted the linksys but without results.


    000 Plutorun started on Wed Apr 4 20:47:31 EST 2007
    001 [Wed 20:47:33] Starting Pluto (Openswan Version 2.4.5dr3 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEr\134[u@aflB_)
    002 [Wed 20:47:33] Setting NAT-Traversal port-4500 floating to off
    003 [Wed 20:47:33] port floating activation criteria nat_t=0/port_fload=1
    004 [Wed 20:47:33] including NAT-Traversal patch (Version 0.6c) [disabled]
    005 [Wed 20:47:33] ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
    006 [Wed 20:47:33] starting up 1 cryptographic helpers
    007 [Wed 20:47:33] started helper pid=340 (fd:5)
    008 [Wed 20:47:33] Using KLIPS IPsec interface code on 2.4.26-uc0
    009 [Wed 20:47:33] Changing to directory '/etc/ipsec.d/cacerts'
    010 [Wed 20:47:33] Changing to directory '/etc/ipsec.d/aacerts'
    011 [Wed 20:47:33] Changing to directory '/etc/ipsec.d/ocspcerts'
    012 [Wed 20:47:33] Changing to directory '/etc/ipsec.d/crls'
    013 [Wed 20:47:33] Warning: empty directory
    014 [Wed 20:47:48] added connection description "TunnelA"
    015 [Wed 20:47:49] listening for IKE messages
    016 [Wed 20:47:49] adding interface ipsec0/eth0 192.168.1.254:500
    017 [Wed 20:47:49] loading secrets from "/etc/ipsec.secrets"
    018 [Wed 20:47:53] "TunnelA" #1: initiating Main Mode
    019 [Wed 20:47:53] "TunnelA" #1: [WRV200 Response:] ISAKMP SA (Main Mode) Initiation
    020 [Wed 20:47:54] "TunnelA" #1: ignoring unknown Vendor ID payload [625027749d5ab97f5616c1602765cf480a3b7d0b]
    021 [Wed 20:47:54] "TunnelA" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    022 [Wed 20:47:54] "TunnelA" #1: STATE_MAIN_I2: sent MI2, expecting MR2
    023 [Wed 20:47:55] "TunnelA" #1: I did not send a certificate because I do not have one.
    024 [Wed 20:47:55] "TunnelA" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    025 [Wed 20:47:55] "TunnelA" #1: STATE_MAIN_I3: sent MI3, expecting MR3
    026 [Wed 20:47:55] "TunnelA" #1: next payload type of ISAKMP Hash Payload has an unknown value: 37
    027 [Wed 20:47:55] "TunnelA" #1: malformed payload in packet
    028 [Wed 20:47:55] "TunnelA" #1: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    029 [Wed 20:47:55] "TunnelA" #1: next payload type of ISAKMP Hash Payload has an unknown value: 86
    030 [Wed 20:47:55] "TunnelA" #1: malformed payload in packet
    031 [Wed 20:48:05] "TunnelA" #1: next payload type of ISAKMP Hash Payload has an unknown value: 237
    032 [Wed 20:48:05] "TunnelA" #1: malformed payload in packet
    033 [Wed 20:48:05] "TunnelA" #1: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    034 [Wed 20:48:25] "TunnelA" #1: next payload type of ISAKMP Hash Payload has an unknown value: 62
    035 [Wed 20:48:25] "TunnelA" #1: malformed payload in packet
    036 [Wed 20:48:25] "TunnelA" #1: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    037 [Wed 20:48:45] "TunnelA" #1: next payload type of ISAKMP Hash Payload has an unknown value: 67
    038 [Wed 20:48:45] "TunnelA" #1: malformed payload in packet
    039 [Wed 20:48:45] "TunnelA" #1: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    040 [Wed 20:49:05] "TunnelA" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
    041 [Wed 20:49:05] "TunnelA" #1: starting keying attempt 2 of at most 3
    042 [Wed 20:49:05] "TunnelA" #2: initiating Main Mode to replace #1
    043 [Wed 20:49:06] "TunnelA" #2: ignoring unknown Vendor ID payload [625027749d5ab97f5616c1602765cf480a3b7d0b]
    044 [Wed 20:49:06] "TunnelA" #2: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    045 [Wed 20:49:06] "TunnelA" #2: STATE_MAIN_I2: sent MI2, expecting MR2
    046 [Wed 20:49:07] "TunnelA" #2: I did not send a certificate because I do not have one.
    047 [Wed 20:49:07] "TunnelA" #2: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    048 [Wed 20:49:07] "TunnelA" #2: STATE_MAIN_I3: sent MI3, expecting MR3
    049 [Wed 20:49:07] "TunnelA" #2: next payload type of ISAKMP Hash Payload has an unknown value: 27
    050 [Wed 20:49:07] "TunnelA" #2: malformed payload in packet
    051 [Wed 20:49:07] "TunnelA" #2: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    052 [Wed 20:49:07] "TunnelA" #2: Informational Exchange message is invalid because it has a previously used Message ID (0xe375b521)
    053 [Wed 20:49:17] "TunnelA" #2: next payload type of ISAKMP Hash Payload has an unknown value: 44
    054 [Wed 20:49:17] "TunnelA" #2: malformed payload in packet
    055 [Wed 20:49:17] "TunnelA" #2: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    056 [Wed 20:49:37] "TunnelA" #2: next payload type of ISAKMP Hash Payload has an unknown value: 154
    057 [Wed 20:49:37] "TunnelA" #2: malformed payload in packet
    058 [Wed 20:49:37] "TunnelA" #2: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    059 [Wed 20:50:05] "TunnelA" #2: next payload type of ISAKMP Hash Payload has an unknown value: 128
    060 [Wed 20:50:05] "TunnelA" #2: malformed payload in packet
    061 [Wed 20:50:05] "TunnelA" #2: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    062 [Wed 20:50:17] "TunnelA" #2: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
    063 [Wed 20:50:17] "TunnelA" #2: starting keying attempt 3 of at most 3
    064 [Wed 20:50:17] "TunnelA" #3: initiating Main Mode to replace #2
    065 [Wed 20:50:18] "TunnelA" #3: ignoring unknown Vendor ID payload [625027749d5ab97f5616c1602765cf480a3b7d0b]
    066 [Wed 20:50:18] "TunnelA" #3: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    067 [Wed 20:50:18] "TunnelA" #3: STATE_MAIN_I2: sent MI2, expecting MR2
    068 [Wed 20:50:19] "TunnelA" #3: I did not send a certificate because I do not have one.
    069 [Wed 20:50:19] "TunnelA" #3: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    070 [Wed 20:50:19] "TunnelA" #3: STATE_MAIN_I3: sent MI3, expecting MR3
    071 [Wed 20:50:19] "TunnelA" #3: next payload type of ISAKMP Hash Payload has an unknown value: 57
    072 [Wed 20:50:19] "TunnelA" #3: malformed payload in packet
    073 [Wed 20:50:19] "TunnelA" #3: sending notification PAYLOAD_MALFORMED to 123.123.123.123:500
    074 [Wed 20:50:19] "TunnelA" #3: next payload type of ISAKMP Hash Payload has an unknown value: 118
    075 [Wed 20:50:19] "TunnelA" #3: malformed payload in packet
     
  6. HughR

    HughR LI Guru Member

    It does look like an authentication failure. Are both sides interpreting your string the same way? Perhaps one thinks you are entering the key in hex and the other thinks that you are entering it in ASCII.

    Is there anything interesting in the log on the other side?
     
  7. thelinksysuser

    thelinksysuser LI Guru Member

    I receive on the zyxel these messages.

    No. Time Source IP Destination IP Note
    1|04/05/2007 19:43:45 |111.222.111.222 |123.123.123.123 |IKE
    Rule [1] Phase 1 ID mismatch

    End of Alert

    No. Time Source IP Destination IP Note
    1|04/05/2007 19:43:45 |111.222.111.222 |123.123.123.123 |IKE
    Rule [1] ID content mismatch

    End of Alert

    The source is the Linksys wrv200 and the destingation is the Zyxel.
     
  8. thelinksysuser

    thelinksysuser LI Guru Member

    I ve a status update.

    I ve fixed the tunnel by do the following.

    On the zyxel there is the option "Secure Gateway Address". When i put in a 0.0.0.0 and not the public ip of my Linksys WRV200 then the tunnel can be initiated by the Linksys. It is strange but it is working.

    Is there a explanation for such behaviour?
     
  9. HughR

    HughR LI Guru Member

    Well, it sure looks as if the Zyxel doesn't like the ID payload from the WRV200. Not too surprising. Too bad it does not tell you what ID it got nor what ID it would have accepted (although the latter is a little harder because it is a list and may not be easily constructed from the policies).
     
  10. HughR

    HughR LI Guru Member

    Pure guess: the 0.0.0.0 probably is treated as a special case by the Zyxel (I know that it is in FreeS/WAN). It prevents the Zyxel from initiating (it doesn't know where to send initiating packets). It might means "from anywhere". I wonder why it would affect which ID payloads would be accepted.
     

Share This Page