cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1585
Views
0
Helpful
1
Replies

PPTP pass through ASA not working with PPTP inspection enabled

Jaroslav Ksinan
Level 1
Level 1

Hello,

 

Users from our inside network at work are unable to connect to outside PPTP server through ASA (ASA5515 with SW version 9.8(2)20) with PAT, PPTP is working without issues from home or via mobile hotspot.

 

We have PPTP inspection in place which should be the the only configuration needed to make it work:

 

class-map inspection_default
 match default-inspection-traffic

policy-map global_policy
 class inspection_default
  inspect pptp

service-policy global_policy global


Inspection itself seems to be working as expected for the PPTP control traffic (TCP 1723), but as soon as the PPP LCP negotiation within GRE kicks in, ASA won't let GRE traffic back inside to the client so it's not possible to successfully negotiate the tunnel (packet capture at client workstation only shows PPP LCP "Configuration Request" sent several times to the server but no communication coming back from the server, whereas packet capture on ASA outside interface also shows desired PPP LCP communication from the server, it just decides not to pass it through to the inside).

 

PPTP inspection getting hitcounts as expected:

 

FBTS-INET/pri/act# sh service-policy

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: pptp, packet 46, lock fail 0, drop 0, reset-drop 0, 5-min-pkt-rate 0 pkts/sec, v6-fail-close 0 sctp-drop-override 0

 

PPTP debug showing control communication between client and the server:

PPTP start-control-request: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP start-control-reply: (inside:10.65.5.30/59794 <- outside:193.X.X.X/1723)
PPTP outgoing-call-request: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP outgoing-call-reply: (inside:10.65.5.30/59794 <- outside:193.X.X.X/1723)
PPTP set-link-info: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP set-link-info: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP clear-request: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP disconnect-notify: (inside:10.65.5.30/59794 <- outside:193.X.X.X/1723)
PPTP unknown-message: (inside:10.65.5.30/59794 -> outside:193.X.X.X/1723)
PPTP unknown-message: (inside:10.65.5.30/59794 <- outside:193.X.X.X/1723)

 

Further investigation with asp-drop capture shows GRE traffic coming back from the server to ASA dropped due to (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate. This indicates me that something is wrong with the PPTP inspection as it should make ASA aware about GRE traffic being related to allowed TCP control traffic for PPTP and ASA should then permit traffic coming back.

 

600: 10:43:14.887863       802.1Q vlan#1100 P0 193.X.X.X > 185.Y.Y.Y:  ip-proto-47, length 73 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
601: 10:43:14.887924       802.1Q vlan#1100 P0 193.X.X.X > 185.Y.Y.Y:  ip-proto-47, length 37 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
687: 10:43:16.887069       802.1Q vlan#1100 P0 193.X.X.X > 185.Y.Y.Y:  ip-proto-47, length 41 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
689: 10:43:16.913984       802.1Q vlan#1100 P0 193.X.X.X > 185.Y.Y.Y:  ip-proto-47, length 69 Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate

Any idea, please?

1 Accepted Solution

Accepted Solutions

Jaroslav Ksinan
Level 1
Level 1

Okay, I found the issue, after getting asp-drop nat-no-xlate-to-pat-pool error, I started to look at the translations in show xlate.

 

I found out that our PAT rule for traffic going to internet (which was working perfectly fine for everything else) was in fact defined as static PAT istead of dynamic PAT.

 

nat (inside,outside) after-auto source static any USERS_PUB

 

 

This caused the translations in xlate table defined as "NAT from inside..." and when returning GRE traffic arrived, ASA was apparently looking for "PAT" entry, so I changed the NAT statement to dynamic PAT:

nat (inside,outside) after-auto source dynamic any USERS_PUB

 

This caused the translations to show as "PAT" and everything is working now as expected

 

TCP PAT from inside:10.65.5.30/61905 to outside:185.Y.Y.Y/61905 flags ri idle 0:01:00 timeout 0:05:00
GRE PAT from inside:10.65.5.30/1723 to outside:185.Y.Y.Y/1723 flags ri idle 0:01:00 timeout 0:05:00
GRE PAT from inside:10.65.5.30/24768 to outside:185.Y.Y.Y/24768 flags ri idle 0:01:00 timeout 0:05:00

 

 

View solution in original post

1 Reply 1

Jaroslav Ksinan
Level 1
Level 1

Okay, I found the issue, after getting asp-drop nat-no-xlate-to-pat-pool error, I started to look at the translations in show xlate.

 

I found out that our PAT rule for traffic going to internet (which was working perfectly fine for everything else) was in fact defined as static PAT istead of dynamic PAT.

 

nat (inside,outside) after-auto source static any USERS_PUB

 

 

This caused the translations in xlate table defined as "NAT from inside..." and when returning GRE traffic arrived, ASA was apparently looking for "PAT" entry, so I changed the NAT statement to dynamic PAT:

nat (inside,outside) after-auto source dynamic any USERS_PUB

 

This caused the translations to show as "PAT" and everything is working now as expected

 

TCP PAT from inside:10.65.5.30/61905 to outside:185.Y.Y.Y/61905 flags ri idle 0:01:00 timeout 0:05:00
GRE PAT from inside:10.65.5.30/1723 to outside:185.Y.Y.Y/1723 flags ri idle 0:01:00 timeout 0:05:00
GRE PAT from inside:10.65.5.30/24768 to outside:185.Y.Y.Y/24768 flags ri idle 0:01:00 timeout 0:05:00