1841 Border Router & Pix 501 -721 PPTP error

[mbalasko]

I hope someone can help me here. I have an 1841 Border router with a pix 501 behind it. I am using the 1841 to handle PAT and allowing the pix to handle the VPN terminations for remote users. The users are going to be using WinXP for PPTP.

I have tested the pix and PPTP is working correctly on it. (I plugged into it via an xover cable and launched my client and the tunnel was established and behaved as expected.) When I plug the Pix outside into my 1841 inside port is when things break.

I get a -721 error on the client and it basically hangs at verify username and pw.

When I launch the tunnel from the client I see this on the pix.(Tried it a few times) (There is no nat or pat being performed on the pix. )

Tnl 26 PPTP: Tunnel created; peer initiated

Tnl 26 PPTP: SCCRQ-ok -> state change wt-sccrq to estabd

Tnl/Cl 26/26 PPTP: l2x store session: tunnel id 26, session id 26, hash_ix=26

Tnl/Cl 26/26 PPTP: vacc-ok -> state change wt-vacc to estabd

Tnl/Cl 26/26 PPTP: ClearReq -> state change estabd to terminal

Tnl/Cl 26/26 PPTP: Destroying session

Tnl 26 PPTP: no-sess -> state change estabd to wt-stprp

Tnl 26 PPTP: StopCCRQ -> state change wt-stprp to wt-stprp

Tnl 26 PPTP: Destroy tunnel

Tnl 27 PPTP: Tunnel created; peer initiated

Tnl 27 PPTP: SCCRQ-ok -> state change wt-sccrq to estabd

Tnl/Cl 27/27 PPTP: l2x store session: tunnel id 27, session id 27, hash_ix=27

Tnl/Cl 27/27 PPTP: vacc-ok -> state change wt-vacc to estabd

Tnl/Cl 27/27 PPTP: ClearReq -> state change estabd to terminal

Tnl/Cl 27/27 PPTP: Destroying session

Tnl 27 PPTP: no-sess -> state change estabd to wt-stprp

Tnl 27 PPTP: StopCCRQ -> state change wt-stprp to wt-stprp

Tnl 27 PPTP: Destroy tunnel

Tnl 28 PPTP: Tunnel created; peer initiated

Tnl 28 PPTP: SCCRQ-ok -> state change wt-sccrq to estabd

Tnl/Cl 28/28 PPTP: l2x store session: tunnel id 28, session id 28, hash_ix=28

Tnl/Cl 28/28 PPTP: vacc-ok -> state change wt-vacc to estabd

Tnl/Cl 28/28 PPTP: ClearReq -> state change estabd to terminal

Tnl/Cl 28/28 PPTP: Destroying session

Tnl 28 PPTP: no-sess -> state change estabd to wt-stprp

Tnl 28 PPTP: StopCCRQ -> state change wt-stprp to wt-stprp

Tnl 28 PPTP: Destroy tunnel

On the 1841 I see the translations get built.(I think)

panlig_border_1841#sho ip nat trans

Pro Inside global Inside local Outside local Outside global

tcp 10.69.1.250:23 10.69.1.250:23 10.69.1.30:1233 10.69.1.30:1233

tcp 10.69.1.250:4399 172.16.5.250:4399 10.69.1.30:445 10.69.1.30:445

tcp 10.69.1.250:1723 192.168.99.249:1723 10.69.1.30:1100 10.69.1.30:1100

gre 10.69.1.250:32768 192.168.99.249:32768 10.69.1.30:32768 10.69.1.30:32768

I see the GRE_PPTP ACL gte hits(Except GRE weird?)

Extended IP access list GRE_PPTP

10 permit gre any any log

20 permit tcp any any eq 1723 log (4 matches)

21 permit tcp any any established (1548 matches)

I used to have a ip nat source static 1723 statement in there, but I couldn't even get that to get me to a 721

error. It basically gave me an 800 vpn server not responding, and I'd never see the pptp request hit the pix.

Let me know if you need any more info to help. I'll buy the beers:)

1841-outside address 10.69.1.250 - Default route to 10.69.1.254 its upstream neighbor.

1841- inside to pix- 192.168.99.254

Pix 501-outside- 192.168.99.249

PPTP address pool- 172.16.253.10-50

Internal addresses behind the pix- 172.161.1.0,172.16.2.0 and 172.16.3.0

1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(1a), RELEASE SOFTWARE (fc2)

1841 Router Config-

[gfullage]

Not sure what you're trying to do with the "ip nat destination" commands in there. To pass PPTP traffic through the router to the PIX's outside interface you need a static NAT translation (not PAT) for th ePIX's outside address, only then will the router pass both the TCP/1723 AND the GRE packets through correctly.

Remove all the NAT stuff you currently have for the PPTP connection, and add just the following:

ip nat inside source static 192.168.99.249 10.69.1.251

Your users will then connect to 10.69.1.251 on their PPTP connection and the router will forward those packets straight thru to the PIX. The connection should then proceed correctly.

You'll notice that you need a second external IP address for this, unfortunately there's no way around this.

[mbalasko]

Okay, so I have a serious headache. I pounded at this for a few more hours and came up with.

ip nat pool panlight1841 10.69.1.250 10.69.1.250 netmask 255.255.255.0 type rotary

ip nat pool PIX 192.168.99.249 192.168.99.249 netmask 255.255.255.0 type rotary

ip nat inside source list all-out interface FastEthernet0/0 overload

ip nat inside source static tcp 192.168.99.249 1723 interface FastEthernet0/0 1723

ip nat inside source static udp 192.168.99.249 500 interface FastEthernet0/0 500

ip nat inside destination list GRE_PPTP pool PIX

ip nat inside destination list rem_manage pool panlight1841

!

ip access-list standard all-out

permit any

!

ip access-list extended GRE_PPTP

permit gre any any log

permit tcp any any established

deny ip any any log

And I think it works!!!! I authenticate and I am also able to ping the inside router. (The router that is beyond the pix's inside interface.) I'll see tomorrow and figure out if I can actually do anything like telnet or map a drive. Its late.

Thanks for your help, and I'll post if this thing actually works.

[mbalasko]

I pounded away at this for a good couple of hours. Perseverance payed off. I was limited to one IP address because the inet provider here is totally unresponsive to my request for a second IP. This just had to work. In the configs I am using private addresses on both sides of the tunnel, but that will change once this goes production. (next week)

I am happy to say that I am successfully pushing/Nat'ing PPTP through the 1841 to the Outside of the pix and I only have one external IP. The test PPTP tunnel is to the 1841 outside address.

The static statment handles the 1723, and the ACL handles the GRE push through/translation.

See the enclosed attachments for a sanity check. But I was able to ping, map drives and copy a file.

I know in your email you said there is no way around it, but I think I found a way around it that appears to be working well.

Let me know what you think.

Thank you,

Mike