PPTP Passthrough ASA 9.x

[edatwyler]

I recently installed a new ASA 5515-X with software version 9.1 installed.  Everything is working great except for outbound PPTP VPN connections to remote servers.  I have enabled PPTP inspection like I have with other installations but the PPTP connections keeps getting stuck at the username/password prompt.  Below is what I have from a "debug pptp" with x.x.x.x being the client IP and y.y.y.y being the remote server IP.  Any assistance would be greatly appreciated.

PPTP start-control-request: (inside:x.x.x.x/51181 -> outside:y.y.y.y/1723)

PPTP start-control-reply: (inside:x.x.x.x/51181 <- outside:y.y.y.y/1723)

PPTP outgoing-call-request: (inside:x.x.x.x/51181 -> outside:y.y.y.y/1723)

PPTP outgoing-call-reply: (inside:x.x.x.x/51181 <- outside:y.y.y.y/1723)

PPTP set-link-info: (inside:x.x.x.x/51181 -> outside:y.y.y.y/1723)

PPTP clear-request: (inside:x.x.x.x/51181 <- outside:y.y.y.y/1723)

PPTP disconnect-notify: (inside:x.x.x.x/51181 -> outside:y.y.y.y/1723)

PPTP unknown-message: (inside:x.x.x.x/51181 -> outside:y.y.y.y/1723)

PPTP unknown-message: (inside:x.x.x.x/51181 <- outside:y.y.y.y/1723)

[hmajidy2001]

Having the same problem in 9.1(1) which existed in 8.3(2). Here's the debug from a session:

PPTP start-control-request: (inside:10.0.1.89/41245 -> outside:w.x.y.z/1723)

PPTP start-control-reply: (inside:10.0.1.89/41245 <- outside:w.x.y.z/1723)

PPTP outgoing-call-request: (inside:10.0.1.89/41245 -> outside:w.x.y.z/1723)

PPTP outgoing-call-reply: (inside:10.0.1.89/41245 <- outside:w.x.y.z/1723)

PPTP outgoing-call-reply: (inside:10.0.1.89/41245 <- outside:w.x.y.z/1723)

PPTP set-link-info: (inside:10.0.1.89/41245 -> outside:w.x.y.z/1723)

PPTP set-link-info: (inside:10.0.1.89/41245 -> outside:w.x.y.z/1723)

PPTP set-link-info: (inside:10.0.1.89/41245 -> outside:w.x.y.z/1723)

Inspect pptp is turned. I only have a single public IP on the outside, so dedicating a second public IP is not feasible. A solution that will work for any PPTP client on the inside would be nice but not required.

Thanks,

Hammer

[David Kron]

I am seeing this exact same issue. Is there any workaround for the problem?

[Julio Carvajal]

Hello David

Can you provide your configuration?

Check my blog at http:laguiadelnetworking.com for further information.

Cheers,

Julio Carvajal Segura

[David Kron]

It's a 5505 running 9.1(1) as far as relevant config goes, we've got pptp allowed out and have enabled pptp inspection as shown below. When a user tries to connect using a windows 7 native VPN to an outside server, I get the same debug output as the others above. On other ASAs with older firmware versions, things work fine but this particular firewall needed the later firmware for the expanded NAT functionality.

access-list acl_internal_out extended permit tcp any any eq pptp

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect sqlnet

  inspect skinny

  inspect sunrpc

  inspect xdmcp

  inspect sip

  inspect netbios

  inspect tftp

  inspect ip-options

  inspect pptp

!

service-policy global_policy global

[Julio Carvajal]

Hello David,

The PPTP inspection should be doing it, certanly not expected at all.

Can you share

show service-policy

What do the logs tell you while the issue happens?

Check my blog at http:laguiadelnetworking.com for further information.

Cheers,

Julio Carvajal Segura

[David Kron]

Ok I finally figured out my problem.

The new site that was having this problem had all fresh equipment. A couple of C3750Xs, a pair of ASAs in active/passive and 3 standalone Aironet 1140s. I had been blaming the ASA for the pptp problem when in fact it had nothing to do with it all along! It was actually a problem with the freaking Aironets.

per: https://supportforums.cisco.com/thread/1003257

I hadn't even considered this as a possibility and had happily tried my various pptp connection attempts exclusively via wifi, as had all of the users who originally reported the problem. Simply upgraded the 1140 firmware as mentioned in that thread and it all started working. Check your aironet firmware if you are using cisco wifi!