PIX 501 VPN - I can ping but can't map a drive

Yes, udp 161 is the SNMP protocol; HP's monitoring service in particular likes to use SNMP to talk to the printer.

In combination with the nat 0 access-list, that entry says that packets between the one inside host 192.168.0.250 and the "outside" network 192.168.4.0 - 192.168.4.15 are not to undergo address translation -and- that you do not need a 'static' command for that traffic.

But if you look at the destination IP for the SNMP traffic, you will see that it is not 192.168.0.250, so that nat exemption ACL does not apply. Therefore what does apply to this case is the normal public address translation and public ACLs, just as if the traffic was not coming in via VPN.

Your normal applicable ACLs and translations are:

Those ACLs say that when that selected traffic comes from outside to the *outside* ("public") IP 192.168.0.250, that it should be permitted, but the only traffic allowed to any other public IP should be the icmp traffic. [That's why you can ping.] But is 192.168.0.250 the public IP of the inside host 192.168.0.250 ?

Nope, it isn't. That line says that except for the traffic exempted by the inside_outbound_nat0_acl ACL, that the inside host 192.168.0.250 should be represented on the outside by the *host* IP address

We see that the source IP for those packets is not in the 192.168.4.0 -

Now, what is puzzling is why the PC is using the 192.168.3.4 source IP. If the PC did indeed connect through the VPN, then it should have been assigned an IP out of pool SS by the PPTP process, which would have given it an IP in the 192.168.4.0 - 192.168.4.15 network for which the address exemption would have applied (and thus the msnet ACL would have worked as well.)

Is it possible that somehow the PC is talking to the PIX directly, instead of through a VPN? Does the outside PC just happen to be on the network segment that the PIX outside interface is on? In that if it does happen to be on that outside interface, then its traffic to the reserved private IP 192.168.0.250 would have been able to get through, but if there is any public infrastructure between the PC and the PIX then normal public routing processes would not have been able to find your PIX, since 192.168.*.* traffic would normally get dropped.

Anyhow, putting these things together:

- you need to expand your access-list inside_outbound_nat0_acl so that the source is not just the host 192.168.0.250: it should include all the inside hosts that are to be reached (e.g., the printer.)

- you need to drop that static for the inside IP 192.168.0.250 -- it isn't doing you any good. You are dhcp'ing for an outside IP, so it isn't the case that you want 192.168.0.250 to be a public server that needs to be static'd to a public IP.

- you should adjust your outside ACLs to only allow the 192.168.4.0-15 network as the source IPs -- otherwise, attackers that -happen- to randomly (or sequentially) try your IP address might be able to get UDP packets through and exploit some NETBIOS vulnerability. Alternately, you could drop your outside ACL and turn on sysopt connection permit-pptp which would allow pptp clients to access -all- hosts (and ports) in your LAN, no matter what the ACLs said.

- you need to figure out why the PPTP client is not being assigned an IP from the pool SS. I don't have any good ideas on this one [other than the possibility that it skipped the PPTP layer and is right there on the outside segment...]

Walter Roberson wrote: [...considerable snippage...]

Walter, thank you very much for your analysis and response. Very helpful -- especially as I am a novice to all this.

Apparently, also the Lexmark TCP/IP print server.

Yes, the PC *was* in the same segment as the outside interface of the PIX. It was interesting that ping traffic was using the VPN assigned IP address from the VPN pool but NET USE was using the IP address that was on the same segment of the outside interface of the PIX.

I now have the PC out on the internet with an IP of 69.x.x.x and the perimeter firewall 71.x.x.x now routes TCP port 1723 and GRE stuff into the PIX outside address. From the perimeter firewall log:

Sat, 2006-01-21 15:20:54 - TCP Packet - Source:69.x.x.x,10013 Destination:192.168.3.2,1723 - [VPN-PPTP match] Sat, 2006-01-21 15:20:55 - GRE Packet - Source:69.x.x.x Destination:192.168.3.2 - [VPN-PPTP Data match]

And, sure enough, the PC at 69.x.x.x can now authenticate on the PIX by connecting to the public 71.x.x.x address. I get an IP address from within the VPN pool: 192.168.4.1.

But, I get no further. I can't ping the internal servers or map a drive.

I think I've done all the items you outlined in your post but I may have fouled something else up or not understood what I was doing well enough to properly carry out your suggestions.

Here's my current config:

PIX Version 6.3(4) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password ********** encrypted passwd ********** encrypted hostname pixfirewall domain-name ciscopix.com 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 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list msvpn permit ip 192.168.4.0 255.255.255.240 192.168.0.0

Thanks again, Walter, I guess I need another lesson.