10-14-2020 04:11 AM
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?
Solved! Go to Solution.
10-14-2020 04:57 AM
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
10-14-2020 04:57 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide