cannot respond to IPsec SA request because no connection.

[wanaBateki]

Hi,

I'm new to this forum and VPN!!!

I'm pretty sure I'm very close to setting up a (the first) VPN tunnel from home to my office.

We have a netgear fvs318 at the office
I have a netgear dg814 at home
Both ends are connected to the internet via ADSL
I have successfully tested the tunnel using a analogue modem

But...
When I try to connect using adsl, the phase two IKE fails with the error above (see subject).

Any tips appreciated.

thanks,

Jago

 

[deeno]

I'm guessing it's a deal with IPSec Pass Through on the client side. What client are you using to connect??

Anyway, to correct this, check to see if there is an IPSec Pass Through option on your router at home. This option needs to be enabled.

The reason it's working through dialup is because with the dialup you are not going through a router, and thus you do not have the "pass through" problem.

Hope you get it...

deeno

 

[wanaBateki]

cheers deeno.

I thought that if i'm getting to phase two IKE, then the VPN pass through is OK?

Basically, it is very close to completing the connection.

What do you think?

Jago

 

[deeno]

I had a problem where Phase 1 would successfully complete, but Phase 2 would fail.

Come to think of it, your problem probably isn’t pass through.

For the Linksys products (which I am more familiar with), if you are attempting to connect to a VPN server/device from behind a router, you must configure the VPN connection on the server for group VPN. There may also be a NAT-T option or something similar on the VPN server.

Anyway, best guess would have it that the problem is occurring on the server side of the connection. Sorry for the last post, it is probably not a pass through problem on the client side.

deeno

 

[chicocouk]

Actually, I think it is a pass through problem.

Phase one uses UDP port 500 to negotiate the SA, Phase 2 will then use ESP, which is a protocol. UDP traffic can be nat-ed with no problem whatsoever, ESP cannot (because ESP is portless). The only way for it to properly pass nat is to encapsulate it within UDP traffic, (if your vpn endpoints support NAT-t)

The IpSec pass through is a fudge, the router notes where ESP traffic initiates from inside the network, and nats all ESP traffic back to that local ip. This falls over when there's more than one vpn endpoint behind a NAT device. IpSec pass through is a cheap and cheerful workaround for Nat-t.

So i reckon deeno's probably right. I suspect the netgears probably won't support NAT-t, so you'll need to enable IpSec pass-through on the router, if that feature's available.

Of course, if the netgears support nat-t, turn that on, and job done.

Chico

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[deeno]

What made me reconsider my original post is that I can reproduce the problem with Phase 2 by making a configuration change on my Linksys Router/VPN server. Without the IPSec Pass Through selected on the client side of the VPN, I don’t think the Phase 1 would work unless you were to configure port forwarding. Even then I could be mistaken.

My best guess is that there is something wrong on the Netgear VPN server, not on the client-side Netgear router. Whether or not the problem can be corrected is another question. Like I mentioned in my last post, my Linksys RV082 gives the same error with Phase 2 unless it is configured for a group tunnel. If the group tunnel option is not used, a user from behind a router is unable to connect, but a user directly connected to the Internet (as with a dialup connection) can connect without a problem. Why group tunnel must be selected is beyond me.

So, I’d search for options on the Netgear VPN server that you’re using. If I were more familiar with Netgear products I’d offer more direction. It’s entirely possible that you will be unable to fix the problem until Netgear releases new firmware that addresses the problem.

Good luck...

deeno

 

[wanaBateki]

Thanks guys for all your suggestions and advice.

It seems that it could be a client side problem after all. This is what I thought initially, and subsequently I spent most of the weekend trying to configure my dg814 as a bridge and then use my firewall/router for PPP authentication. Couldn't get it to work anyway!

I have copied and pasted two sections of the server side vpn logs below. One for the successful dialup and the same section of the log for the failed adsl connection. Does this shed any light on the matter?

1. Why/what does "IPsec:New State index:1, sno:5" mean compared to "IPsec:New State index:1, sno:3"?

2. It seems to fail to get the ipsec_spi over adsl?

3. I think I'll get hold of another adsl client device to enable me to eliminate the dg814 from the equation...

I hope you can assist me further on this. Logs follow.

Thanks again everyone.

Jago


Dialup (phase 2 IKE success):
...
IPsec:STATE_MAIN_R3: sent MR3, ISAKMP SA established
IPsec:Receive Packet address:0x1397478 from 62.137.86.xxx
IPsec:New State index:1, sno:5
IKE:[JagoVPN_tmp2] RX << QM_I1 : 62.137.86.xxx
IPsec:in get_ipsec_spi() spi=e4db4a9d
:[ESP_3DES/AUTH_ALGORITHM_HMAC_SHA1/In SPI:e4db4a9d,Out SPI:11fc9f7a]
IPsec:responding to Quick Mode
IPsec: ESP(3DES-CBC SHA-1)
IKE:[JagoVPN_tmp2] TX >> QM_R1 : 62.137.86.xxx
IPsec:inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #5
IPsec:Receive Packet address:0x1397478 from 62.137.86.xxx
IKE:[JagoVPN_tmp2] RX << QM_I2 : 62.137.86.xxx
IPsec: ESP(3DES-CBC SHA-1)
IKE:[JagoVPN_tmp2] established with 62.137.86.xxx successfully
IPsec:inserting event EVENT_SA_EXPIRE, timeout in 28980 seconds for #5
IPsec:STATE_QUICK_R2: IPsec SA established
__________________________________________

ADSL (phase 2 IKE failed)
...
IPsec:STATE_MAIN_R3: sent MR3, ISAKMP SA established
IPsec:Receive Packet address:0x1397478 from 212.84.127.xxx
IPsec:New State index:1, sno:3
IKE:[JagoVPN_tmp1] RX << QM_I1 : 212.84.127.xxx
IPsec:cannot respond to IPsec SA request because no connection is known for 192.168.0.0/255.255.255.0-212.84.114.xxx=====212.84.127.xxx-19
IPsec:Receive Packet address:0x1397478 from 212.84.127.xxx
IPsec:loglog[3] *#hahaha.... next payload type of ISAKMP Hash Payload has an unknown value: 208
IPsec:malformed payload in packet

 

[deeno]

I still believe that your problem is on the server side. I'm not sure that a different client router would help in this case.

Let us know what you find...

deeno