Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PPTP problem

Status
Not open for further replies.

speedingwolf

IS-IT--Management
Jan 23, 2003
65
US
Hello,

I have PIX 515 with 4 interfaces. I have 6.3.3 version and i configured fixup protocol 1723 for PPTP pass through. We have PAT. We have a PPTP server parallel with the PIX. The problem is very strange. A few users can PPTP from inside, or from DMZ to our PPTP server and other can't, including myself. This worked in the past. If i VPN from outside to our PPTP server, no problem. What should i look for? Some users in the DMZ can PPTP back to our corporate network and some can't. Users permissions are the same.

Thanks,
 
HI.

Your scenario is a bit dificult to understand without a diagram or more detailed info. (which device and interface is connected to what).

But anyway, why not start using Cisco VPN which can be better then PPTP in many factors?
Terminate the VPN tunnels at the pix itself, and use the W2K server for IAS only.
What do you think?



Yizhar Hurwitz
 
Hi Yizhar,

Thanks for your respond. I'm new at this stuff so if i do not explain clearly, please pardon me.

We have PIX 515, and a VPN Concentrator 3005. The VPN concentrator allows remote users to use Cisco IPSEC client to connect to our internal net. In addition, it allows pptp VPN as well because we have certain special needs such as wireless VPN using only pptp (Pocket PC, Palm, etc). In the past, users can PPTP from home, outside the firewall, and if they are in the DMZs or Inside, they can pptp back. Since our PIX has 5 interfaces, i use these interfaces for: inside, outside, DMZ, Vendornet, UnsecuredLAN (i put access points in this network).

Then, we have a project with our partner and we need to VPN to their office. The partner has Microsoft PPTP. Users reported that they're unable to connect to our partner PPTP server in our internal network of 10.dot (it turned out our partner net internal is 10.dot as well. So, I came up with an immediate solution. I moved these users from our 10.dot network to our DMZ and UnsecuredLAN and they're successfully PPTP to our partnet net.

Then I realized that A FEW OF us can't PPTP to our Cisco Concentrator 3005 while we are inside our 10.dot network or 192.network. Some were successful. We were able to do this before. I contacted Cisco and they told me to upgraded to version 6.3.3 and gave this command fixup protocol 1723. According to Cisco article, I do not need to open GRE because 6.3.3 solves PAT issue. Then when they need to access our network, they can PPTP or IPSEC back in. Please note that the Concentrator does PPTP and IPSEC, not the PIX. However, I know there is something going at the PIX that gives this strange behavior. Some users can PPTP back while they're inside the DMZ, others can't, including myself. Also, once users in the DMZ networks, they can't see our domain if they type It works only if they type 192.168.100.80, the IP address of the webserver.

Sorry for this long post, my config looks:

: Written by enable_15 at 23:02:30.595 PDT Tue Oct 21 2003
PIX Version 6.3(3)
interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 100full
interface ethernet3 100full
interface ethernet4 100full
interface ethernet5 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 failover security60
nameif ethernet3 DMZ security70
nameif ethernet4 vendornet security55
nameif ethernet5 UnSecuredLAN security65

fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names

access-list noNAT permit ip 10.0.0.0 255.0.0.0 192.168.100.0 255.255.255.0
access-list 100 permit tcp any host MyPublicIP eq smtp
access-list 100 permit tcp any host MyPublicIP eq 993
access-list 100 permit tcp any host MyPublicIP eq www
access-list 100 permit tcp any host MyPublicIP eq https
access-list 100 permit tcp any host MyPublicIP eq https
access-list 100 permit tcp any host MyPublicIP eq www
access-list 100 permit tcp any host MyPublicIP eq ftp
access-list 100 permit tcp any host MyPublicIP eq www
access-list 100 permit tcp any host MyPublicIP eq https
access-list 100 permit tcp any host MyPublicIP eq www
access-list 100 permit tcp any host MyPublicIP eq 8890
access-list 100 permit tcp any host MyPublicIP eq ftp

access-list 100 permit tcp any host 63.76.82.69 eq pptp
access-list 100 permit tcp any host 63.76.82.69 eq www
access-list 100 permit icmp any any

This is DMZ interface

access-list 101 deny ip 0.0.0.0 255.0.0.0 any
access-list 101 deny ip 10.0.0.0 255.0.0.0 any
access-list 101 deny ip 127.0.0.0 255.0.0.0 any
access-list 101 deny ip 172.16.0.0 255.255.0.0 any
access-list 101 deny ip 224.0.0.0 224.255.0.0 any
access-list 101 permit tcp host 192.168.100.80 host 10.0.0.10 eq smtp
access-list 101 permit tcp host 192.168.100.79 host 10.0.1.228 eq 99
access-list 101 permit tcp host 192.168.100.80 host 10.0.0.127 eq 1433
access-list 101 permit icmp host 192.168.100.67 host 10.0.0.13
access-list 101 permit tcp host 192.168.100.69 host 10.0.0.3 eq smtp
access-list 101 remark Permit BridgeHead talks to AD
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq domain
access-list 101 permit udp host 192.168.100.67 host 10.0.0.13 eq domain
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 88
access-list 101 permit udp host 192.168.100.67 host 10.0.0.13 eq 88
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 135
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq ldap
access-list 101 permit udp host 192.168.100.67 host 10.0.0.13 eq 389
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 3268
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 9110
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 445
access-list 101 permit udp host 192.168.100.67 host 10.0.0.13 eq 9110
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.13 eq 1026
access-list 101 remark Permit BridgeHead talks to Payload
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.252 eq imap4
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.252 eq www
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.252 eq smtp
access-list 101 remark Permit BridgeHead talks to Hercules
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.127 eq 1433
access-list 101 permit tcp host 192.168.100.67 host 10.0.0.252 eq 691
access-list 101 permit icmp any any echo-reply
access-list 101 remark Deny DMZ network from Entering 10dot network
access-list 101 deny ip any 10.0.0.0 255.0.0.0
access-list 101 remark Allow DMZ to go outside
access-list 101 permit ip 192.168.100.0 255.255.255.0 any

Another DMZ named UnsecuredLAN for access points

access-list UnsecuredLAN permit icmp any any
access-list UnsecuredLAN permit ip 192.168.0.0 255.255.255.0 any
pager lines 24
logging on
logging timestamp
logging buffered notifications
logging trap debugging
logging facility 4
logging host inside 10.0.17.116
icmp deny any outside
icmp deny any DMZ
mtu outside 1500
mtu inside 1500
mtu failover 1500
mtu DMZ 1500
mtu vendornet 1500
mtu UnSecuredLAN 1500
ip address outside MyPublicIP 255.255.255.224
ip address inside 10.0.0.100 255.255.0.0
ip address failover 192.168.254.1 255.255.255.252
ip address DMZ 192.168.100.1 255.255.255.0
ip address vendornet 192.168.101.1 255.255.255.0
ip address UnSecuredLAN 192.168.0.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
failover
failover timeout 0:00:00
failover poll 15
failover ip address outside MyPublicIP
failover ip address inside 10.0.0.101
failover ip address failover 192.168.254.2
failover ip address DMZ 192.168.100.2
failover ip address vendornet 192.168.101.2
no failover ip address UnSecuredLAN
failover link failover
pdm history enable
arp timeout 14400
global (outside) 1 MyPublicIPNAT netmask 255.255.255.224
global (outside) 2 interface
global (vendornet) 1 192.168.101.3 netmask 255.255.255.0
nat (inside) 0 access-list noNAT
nat (inside) 2 172.16.1.0 255.255.255.0 0 0
nat (inside) 1 10.0.0.0 255.0.0.0 0 0
nat (DMZ) 1 192.168.100.0 255.255.255.0 0 0
nat (UnSecuredLAN) 1 192.168.0.0 255.255.255.0 0 0
static (DMZ,outside) MyPublicIP 192.168.100.100 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.79 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.87 netmask 255.255.255.255 0 0
static (vendornet,outside) MyPublicIP 192.168.101.72 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.66.88 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.101 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.69 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.185 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.106 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.142 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.149 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.4.59 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.9.148 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.67 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.68 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.51.81 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.133 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.177 netmask 255.255.255.255 0 0
static (inside,outside) MyPublicIP 10.0.50.250 netmask 255.255.255.255 0 0
static (DMZ,outside) MyPublicIP 192.168.100.80 dns netmask 255.255.255.255 0 0
access-group 100 in interface outside
access-group 101 in interface DMZ
access-group UnsecuredLAN in interface UnSecuredLAN
route outside 0.0.0.0 0.0.0.0 63.76.82.65 1
route inside 10.4.0.0 255.255.0.0 10.0.0.9 1
route inside 10.10.0.0 255.255.0.0 10.0.0.9 1
route inside 10.11.0.0 255.255.0.0 10.0.0.9 1
route inside 172.16.1.0 255.255.255.0 10.0.0.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet 10.0.0.0 255.255.0.0 inside
telnet timeout 30
ssh 10.0.0.0 255.255.0.0 inside
ssh timeout 30
console timeout 0
dhcpd address 192.168.0.100-192.168.0.200 UnSecuredLAN
dhcpd dns 198.6.1.3 198.6.1.4
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd enable UnSecuredLAN
terminal width 80
Cryptochecksum:b743d5e39c51e118ce3d6a3e74850625
 
HI.

> it allows pptp VPN as well because we have certain special needs such as wireless VPN using only pptp (Pocket PC, Palm, etc).
I think that there is also a Cisco IPSEC VPN client for these handheld platforms, isn't it?

> (it turned out our partner net internal is 10.dot as well. So, I came up with an immediate solution. I moved these users from our 10.dot network to our DMZ
I think that there are better solutions, for example:
Using a terminal server placed in DMZ to initiate outbound VPN connections to the partner. The users that need VPN to that partner will log in to terminal server and run the program from there.
There are other possible variants of this idea - the principle is let one device initiate outbound PPTP client connections on behalf of the other.

> I contacted Cisco and they told me to upgraded to version 6.3.3 and gave this command fixup protocol 1723
There are some limitations to the "fixup protocol pptp" command, for example PPTP version. Take a look here:

> Also, once users in the DMZ networks, they can't see our domain if they type
Maybe the simpliest solution is to implement a DNS server for DMZ zone?




Yizhar Hurwitz
 
Thanks for the respond.

I checked the vendors website and they do not have IPSEC vpn client. Only PPTP client.

For putting a server DMZ and make it a terminal server does not work. I tried that already. For example, once a user from inside connects to the DMZ terminal server and starts the VPN process, he/she will be cut off terminal session because the tunnel gives a different IP range and the terminal session will be disconnected.

I am thinking of putting a DNS server in the DMZ as you recommended.

Thanks,
 
HI.

> For example, once a user from inside connects to the DMZ terminal server and starts the VPN process, he/she will be cut off terminal session

Try to remove that line and then test again:
no nat (inside) 0 access-list noNAT
no access-list noNAT

and add:
global (DMZ) 1 192.168.100.250

That way the terminal server will see internal clients as coming from 192.168.100.250 and will not disconnect them when initiating outbound VPN to another 10.x.x.x network.

However removing the "nat 0" might have other impacts on your network.

Also, if applicable, then at the PPTP VPN dialer, try to disable the option "Use Default Gateway on remote network".



Yizhar Hurwitz
 
H Yizhar,

My PPTP problem seems to solve itself. I do not change anything yet and suddenly I can PPTP from inside network. My pix CPU util is about 25%-47%. I don't know if that would cause the problem. However, the PIX does not do pptp, the VPN concentrator does.

Thanks for your advise.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top