2

I'm trying to set up a L2TP/IPSec VPN on a Windows 7 client, to a Cisco ASA 5505 SecPlus license.

ASA have dual WAN connections:

  • wan1: a mobile 3G connection behind the ISP router, used for Internet browsing.
  • wan2: a DSL connection with "static" DHCP IP, used for incoming firewall traffic.

A static route with tracking is set so if the 3G is down it will failover to DSL:

route wan1 0.0.0.0 0.0.0.0 192.168.98.1 1 track 1

wan2 have this config:

dhcp client route distance 200
ip address dhcp setroute

All that is working fine.

Now I have tried to make a L2TP/IPsec VPN connection from a Windows 7 client to the wan2 interface, I get these errors:

Duplicate first packet detected.  Ignoring packet.
Phase 1 failure:  Mismatched attribute types for class Group Description:  Rcv'd: Unknown  Cfg'd: Group 2

The first error I'm also getting with the "old" Cisco VPN client, using the ASDM Wizard.

ASA version is: 9.1

Question is: Do I miss something? I suspect the dual wan setup to be the problem. Do the ASA send VPN reply back on the default route (wan1)?

/Kim

Improve this question

2 Answers 2

Reset to default
1

You do have asymmetrical routing, but that shouldn't be the issue. Instead, I suspect the issue is link delay involving your 3G link. Since IPSec IKE uses UDP/500 or UDP/4500 with NAT-Traversal, there's no guarantee of packet delivery. Your VPN client -- the IKE initiator -- sends the first IKE message and is awaiting a response from your ASA. The ASA IKE response message is either dropped or delayed too long that your VPN client sends another IKE message, causing the ASA to log the Duplicate first packet received.

I would think your DSL link is more reliable -- less delay, less jitter, less packet loss -- than the 3G mobile network. Any reason that's not your default gateway? To test the 3G link as the issue, force the DSL to be your default.

Improve this answer
7
  • Just so I understand you: The VPN reply packet is sent back on the 3G link? And not on the DSL link where it was initiated?
    – kimr-dk
    Sep 17, 2013 at 9:09
  • The DSL link has slower bandwidth, than the 3G link. The site is far away from the phone central.
    – kimr-dk
    Sep 17, 2013 at 9:11
  • @kimr-dk: Packets are not necessarily going to go back out same interface they were received on. Routing will dictate the path back out which is your default pointing to the 3G. You could run some ping tests to your VPN client w/ ping -l 1272 -f -n 20 <client-ip>, assuming 1300 MTU set by Cisco VPN client, one across the 3G and the other over the DSL. To test to the client over DSL without affecting everyone else, add a /32 static route to the client to force out that interface: route wan2 192.0.2.1 255.255.255.255 1 (where 192.0.2.1 is client-ip). Also look at tools like iperf.
    – generalnetworkerror
    Sep 17, 2013 at 9:25
  • I've now tested with the 3G off and it works perfect. What did you mean by client IP? An IP from the VPN pool? Or that clients public IP?
    – kimr-dk
    Sep 17, 2013 at 19:23
  • @kimr-dk: Client-IP = Client's public IP seen by the ASA and used for routing decision.
    – generalnetworkerror
    Sep 18, 2013 at 7:53
1

I've solved the problem by getting a static IP for the client too, which also was a 3G link. Then I could create that static route for this client only.

The ISP also require both endpoints to have static IP for communication to work as they both are on same ISP.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.