This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Net to Net IPSEC with Linksys?

I am wondering if anyone tried to configure a Net to Net IPSEC tunnel using the Linksys VPN Router (BEFVP41).  On the surface, it seems to support the right authentication and encryption methods (3DES, MD5, PFS, and IKE), but after configuring a tunnel (PFS:Y, SA:ike, with a shared secret) I get this from my ASL log:

peer: c0 a8 00 32 
peer: c0 a8 00 32 
sending: 
state hash entry 1 
state hash entry 23 
state object #13 found, in STATE_MAIN_I1 
state object not found 
state transition function for STATE_MAIN_I1 failed: NO_PROPOSAL_CHOSEN 

This is an exerpt from the linksys log:

IKE[1] Rx > MM_R1 : 192.168.0.100
IKE[1] ISAKMP SA CKI=[ca017c73 b49c9d49] CKR=[1883e3bb d856873]
IKE[1] ISAKMP SA 3DES / SHA / PreShared / MODP_1024 / 3600 sec
IKE[1] TX >> MM_I1 : 192.168.0.100
IKE[1] Rx > MM_R1 : 192.168.0.100
IKE[1] ISAKMP SA CKI=[ca017c73 b49c9d49] CKR=[d8c497d5 87bec920]
IKE[1] ISAKMP SA 3DES / SHA / PreShared / MODP_1024 / 3600 sec

192.168.0.100 is the asl address.  The external ips are on the same subnet, so there is no NAT or connectivity issue.  The internal subnets are 192.168.2.0/24 and 192.168.1.0/24.  They are talking, but probably not speaking the same language.  If anyone has any ideas, I'll give them a try.


This thread was automatically locked due to age.
Parents
  • Jack1,

    Did you ever have any luck with this???????????
  • I have a had a different set of issues when dealing with Astaro and Linksys.  Before I upgraded my Linksys firmware, I was able to create a VPN and was able to communicate using the connection.  However, after one hour, the re-negotiation would fail, and it was necessary to manually re-connect. 

    After I upgraded the firmware, I changed the settings on the Linksys (now that there is a second page of settings).  I chose 1024-bit for both Phase 1 and 2 (which I believe is the lowest supported in FreeSWAN??).  I chose Main Mode, 3DES, MD5, PFS.  I selected PFS also on the Astaro box.  Now the IPSec negotiations are flawless, but no traffic goes over the IPSec connection.  The routes exist in my routing table, but the packets go nowhere.  And, yes, I do have packet filter rules allowing traffic between these networks.

    Thanks in advance,

    Brent
  • Another question I forgot to ask was whether you had tried using the DMZ feature of the Linksys on the ASL?
  • I really have to get some sleep, but I did a little more reading on the linksys site.  My BEFSR41 only has Firmware level 1.39.  Here's a line item from the 1.42.3 level:

    5. Support for multi-IPSec pass-through

    I was unable to locate any clear explanation for this sentence either on linksys.com or in google, but it does sound like the right stuff.  

    I'll play with this stuff another day.
  • To clarify, David, both ends of my connections do show connected.  The logs on both ends suggest that nothing went wrong in the negotiation of the tunnel.  Are you using the most recent firmware, because your issues sound closer to what I was experiencing before I upgraded the firmware and tweaked the settings?

    Brent
  • I am also using masquerading for the network behind the Astaro box.  Is this perhaps the problem?  If I use masquerading and VPN, is there any special configuration that needs to be done?

    Brent
  • Ok.  Compiling various bits of knowledge from the freeswan and iptables sites, it seems to be the case that I would have to exclude the remote network from the masquerading rule.  They suggest something akin to the following:

    iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE

    where the internal addresses are masqueraded for all destinations except the defined network.  

    Is this possibly related to my issue?
  • drbile not that this is going to help right now but it's more for your information.  I have a very similar setup and I am seeing the same problem.  I can integrate my astaro to freeswan no issue but when the connection come up between the linksys and astaro no traffic goes between the two.  Seems to be very strange.
  • Well, I upgraded to 3.2 and all is good.  My VPN has been up, stable and working for 2 days.  I am curious why it wasn't before, but I am not going to complain.

  •  
     [size="1"][ 20 November 2002, 15:47: Message edited by: William Beatty ][/size]
  • What did you do to get this to work???  I am having problems with the connection dropping between the Linksys router and our Astaro firewall
  • Bump to this thread.

    I've got a similar issue with a client using a LinkSys BEFSX41

    It appears there's a bug there where the keytimes for phase 1 and phase 2 are reset to match in their console. I simply created a rule to match here, however now, the Linksys appears to be rekeying every 15-30 seconds, causing traffic interruptions and connection drops for their users, not to mention quickly filling my logs with garbage.

    We've tried PFS, however the device only supports Oakley-CBC, whcih Astaro 3.2 doesn't appear to support. 

    Log snippet:

    Mar 20 11:53:55  Pluto[17535]: "" #30: max number of retransmissions (2) reached STATE_QUICK_I1
    Mar 20 11:53:55  Pluto[17535]: "" #30: starting keying attempt 8 of an unlimited number
    Mar 20 11:53:55  Pluto[17535]: "" #35: initiating Quick Mode PSK+ENCRYPT+TUNNEL+DISABLEARRIVALCHECK to replace #30
    Mar 20 11:53:55  Pluto[17535]: "" #33: ignoring informational payload, type INVALID_ID_INFORMATION
    Mar 20 11:53:55  Pluto[17535]: "" #33: received and ignored informational message
    Mar 20 11:54:09  Pluto[17535]: "" #36: responding to Main Mode
    Mar 20 11:54:12  Pluto[17535]: "" #36: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:12  Pluto[17535]: "" #36: sent MR3, ISAKMP SA established
    Mar 20 11:54:12  Pluto[17535]: "" #37: received HASH(1) does not match computed value in Quick I1
    Mar 20 11:54:17  Pluto[17535]: "" #31: max number of retransmissions (2) reached STATE_MAIN_R2
    Mar 20 11:54:37  Pluto[17535]: "" #38: responding to Main Mode
    Mar 20 11:54:39  Pluto[17535]: "" #38: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:39  Pluto[17535]: "" #38: sent MR3, ISAKMP SA established
    Mar 20 11:54:39  Pluto[17535]: "" #39: responding to Quick Mode
    Mar 20 11:54:39  Pluto[17535]: "" #40: responding to Main Mode
    Mar 20 11:54:39  Pluto[17535]: "" #39: IPsec SA established
    Mar 20 11:54:42  Pluto[17535]: "" #40: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:42  Pluto[17535]: "" #40: sent MR3, ISAKMP SA established
    Mar 20 11:54:42  Pluto[17535]: "" #41: received HASH(1) does not match computed value in Quick I1
    Mar 20 11:54:43  Pluto[17535]: "" #32: max number of retransmissions (2) reached STATE_MAIN_R2
    Mar 20 11:55:05  Pluto[17535]: "" #35: max number of retransmissions (2) reached STATE_QUICK_I1
    Mar 20 11:55:05  Pluto[17535]: "" #35: starting keying attempt 9 of an unlimited number
    Mar 20 11:55:05  Pluto[17535]: "" #42: initiating Quick Mode PSK+ENCRYPT+TUNNEL+DISABLEARRIVALCHECK to replace #35
    Mar 20 11:55:07  Pluto[17535]: "" #43: responding to Main Mode
    Mar 20 11:55:10  Pluto[17535]: "" #43: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:55:10  Pluto[17535]: "" #43: sent MR3, ISAKMP SA established
    Mar 20 11:55:10  Pluto[17535]: "" #44: responding to Main Mode
    Mar 20 11:55:10  Pluto[17535]: "" #45: responding to Quick Mode
    Mar 20 11:55:11  Pluto[17535]: "" #45: IPsec SA established
    Mar 20 11:55:12  Pluto[17535]: "" #44: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:55:12  Pluto[17535]: "" #44: sent MR3, ISAKMP SA established
    Mar 20 11:55:13  Pluto[17535]: "" #46: responding to Quick Mode
     
Reply
  • Bump to this thread.

    I've got a similar issue with a client using a LinkSys BEFSX41

    It appears there's a bug there where the keytimes for phase 1 and phase 2 are reset to match in their console. I simply created a rule to match here, however now, the Linksys appears to be rekeying every 15-30 seconds, causing traffic interruptions and connection drops for their users, not to mention quickly filling my logs with garbage.

    We've tried PFS, however the device only supports Oakley-CBC, whcih Astaro 3.2 doesn't appear to support. 

    Log snippet:

    Mar 20 11:53:55  Pluto[17535]: "" #30: max number of retransmissions (2) reached STATE_QUICK_I1
    Mar 20 11:53:55  Pluto[17535]: "" #30: starting keying attempt 8 of an unlimited number
    Mar 20 11:53:55  Pluto[17535]: "" #35: initiating Quick Mode PSK+ENCRYPT+TUNNEL+DISABLEARRIVALCHECK to replace #30
    Mar 20 11:53:55  Pluto[17535]: "" #33: ignoring informational payload, type INVALID_ID_INFORMATION
    Mar 20 11:53:55  Pluto[17535]: "" #33: received and ignored informational message
    Mar 20 11:54:09  Pluto[17535]: "" #36: responding to Main Mode
    Mar 20 11:54:12  Pluto[17535]: "" #36: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:12  Pluto[17535]: "" #36: sent MR3, ISAKMP SA established
    Mar 20 11:54:12  Pluto[17535]: "" #37: received HASH(1) does not match computed value in Quick I1
    Mar 20 11:54:17  Pluto[17535]: "" #31: max number of retransmissions (2) reached STATE_MAIN_R2
    Mar 20 11:54:37  Pluto[17535]: "" #38: responding to Main Mode
    Mar 20 11:54:39  Pluto[17535]: "" #38: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:39  Pluto[17535]: "" #38: sent MR3, ISAKMP SA established
    Mar 20 11:54:39  Pluto[17535]: "" #39: responding to Quick Mode
    Mar 20 11:54:39  Pluto[17535]: "" #40: responding to Main Mode
    Mar 20 11:54:39  Pluto[17535]: "" #39: IPsec SA established
    Mar 20 11:54:42  Pluto[17535]: "" #40: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:54:42  Pluto[17535]: "" #40: sent MR3, ISAKMP SA established
    Mar 20 11:54:42  Pluto[17535]: "" #41: received HASH(1) does not match computed value in Quick I1
    Mar 20 11:54:43  Pluto[17535]: "" #32: max number of retransmissions (2) reached STATE_MAIN_R2
    Mar 20 11:55:05  Pluto[17535]: "" #35: max number of retransmissions (2) reached STATE_QUICK_I1
    Mar 20 11:55:05  Pluto[17535]: "" #35: starting keying attempt 9 of an unlimited number
    Mar 20 11:55:05  Pluto[17535]: "" #42: initiating Quick Mode PSK+ENCRYPT+TUNNEL+DISABLEARRIVALCHECK to replace #35
    Mar 20 11:55:07  Pluto[17535]: "" #43: responding to Main Mode
    Mar 20 11:55:10  Pluto[17535]: "" #43: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:55:10  Pluto[17535]: "" #43: sent MR3, ISAKMP SA established
    Mar 20 11:55:10  Pluto[17535]: "" #44: responding to Main Mode
    Mar 20 11:55:10  Pluto[17535]: "" #45: responding to Quick Mode
    Mar 20 11:55:11  Pluto[17535]: "" #45: IPsec SA established
    Mar 20 11:55:12  Pluto[17535]: "" #44: Peer ID is ID_IPV4_ADDR: ''
    Mar 20 11:55:12  Pluto[17535]: "" #44: sent MR3, ISAKMP SA established
    Mar 20 11:55:13  Pluto[17535]: "" #46: responding to Quick Mode
     
Children
No Data