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

Discussion in 'Cisco' started by Hank Zoeller, Jan 21, 2006.

  1. Hank Zoeller

    Hank Zoeller Guest

    Hello,

    I'm trying to set up a VPN connection from a PC outside the PIX 501 into
    a file server. On the outside PC I'm using the Microsoft VPN client
    software.

    I get authenticated on the VPN circuit and can ping (~3 ms.) the server
    (192.168.0.250) but I can't map a drive or access the server in any
    useful way. I do not have a WINS or DNS server running and am simply
    trying to map a drive using the \\192.168.0.250\ShareName method. The
    share name is valid. On the client PC I get the message, "The specified
    network name is no longer available."

    I do see messages in the PIX log like the following but, as I am new to
    all this, I don't know if these messages are relevant.

    "PIX-3-305005: No translation group found for tcp src
    outside:192.168.3.4/1561 dst inside:192.168.0.250/139"

    The 192.168.3.4 IP is the outside PC's normal IP address and the above
    log messages happens when I try to map a drive on the server.

    I also get the following log message:

    "PIX-3-305005: No translation group found for udp src outside:
    192.168.4.1/1025 dst inside:192.168.0.100/161"

    Which (I think) is the outside PC trying to establish contact with an
    internal print server. The 192.168.4.1 IP address is the address given
    to the outside PC from the pool of VPN addresses in the PIX.

    Here's my config:

    PIX Version 6.3(4)
    interface ethernet0 auto
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password xxxxxxxxxxxx encrypted
    passwd xxxxxxxxxxxxx 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 msnet permit tcp any host 192.168.0.250 eq netbios-ssn
    access-list msnet permit udp any host 192.168.0.250 eq netbios-dgm
    access-list msnet permit udp any host 192.168.0.250 eq netbios-ns
    access-list msnet permit icmp any any
    access-list inside_outbound_nat0_acl permit ip host 192.168.0.250
    192.168.4.0 255.255.255.240
    pager lines 24
    logging on
    logging timestamp
    logging trap notifications
    logging host inside 192.168.0.253
    mtu outside 1500
    mtu inside 1500
    ip address outside dhcp setroute
    ip address inside 192.168.0.1 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool SS 192.168.4.1-192.168.4.11
    pdm location 192.168.0.250 255.255.255.255 inside
    pdm location 192.168.0.254 255.255.255.255 inside
    pdm location 192.168.4.0 255.255.255.240 outside
    pdm logging informational 100
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 0 access-list inside_outbound_nat0_acl
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    static (inside,outside) 192.168.4.0 192.168.0.250 netmask
    255.255.255.255 0 0
    access-group msnet in interface outside
    timeout xlate 0:05: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 TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.0.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-pptp
    telnet 192.168.0.0 255.255.255.0 inside
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    vpdn group PPTP-VPDN-GROUP accept dialin pptp
    vpdn group PPTP-VPDN-GROUP ppp authentication pap
    vpdn group PPTP-VPDN-GROUP ppp authentication chap
    vpdn group PPTP-VPDN-GROUP ppp authentication mschap
    vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
    vpdn group PPTP-VPDN-GROUP client configuration address local SS
    vpdn group PPTP-VPDN-GROUP pptp echo 60
    vpdn group PPTP-VPDN-GROUP client authentication local
    vpdn username xxxxx password *********
    vpdn enable outside
    dhcpd address 192.168.0.2-192.168.0.33 inside
    dhcpd lease 3600
    dhcpd ping_timeout 750
    dhcpd auto_config outside
    dhcpd enable inside
    terminal width 80
    Cryptochecksum:b1e039a239a03680c43302546ee79164
    : end

    I have little doubt that I'm missing something or have done something
    wrong. Thank you for any tips or pointers!
     
    Hank Zoeller, Jan 21, 2006
    #1
    1. Advertisements

  2. [re-arranged to make the answers a bit easier to follow]
    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
    192.168.4.0 ... and that's going to apply even if 192.168.0.250 is
    trying to talk to a host outside the VPN, such as if it is trying to
    talk to a DNS server.
    We see that the source IP for those packets is not in the 192.168.4.0 -
    192.168.4.15 subnet, so the normal outside ACL is in charge and
    is denying that traffic. Remember here that as far as the PIX is
    concerned, if the inside_outbound_nat0_acl does not apply then
    the public IP of 192.168.0.250 is the -host- IP 192.168.4.0 .
    For packets with the PC's 192.168.3.4 source IP to have gotten through,
    the msnet ACL would have had to have named "host 192.168.4.0"
    as the destination address, because outside ACLs work on the basis
    of the -outside- version of the IPs.
    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, Jan 21, 2006
    #2
    1. Advertisements

  3. Hank Zoeller

    Hank Zoeller Guest

    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
    255.255.255.0
    access-list inside_outbound_nat0_acl permit ip any 192.168.4.0
    255.255.255.240
    pager lines 24
    logging on
    logging timestamp
    logging trap informational
    logging host inside 192.168.0.253
    mtu outside 1500
    mtu inside 1500
    ip address outside dhcp setroute
    ip address inside 192.168.0.1 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool SS 192.168.4.1-192.168.4.11
    pdm location 192.168.0.250 255.255.255.255 inside
    pdm location 192.168.0.254 255.255.255.255 inside
    pdm location 192.168.0.253 255.255.255.255 inside
    pdm logging informational 100
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 0 access-list inside_outbound_nat0_acl
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    timeout xlate 0:05: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 TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.0.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-pptp
    telnet 192.168.0.0 255.255.255.0 inside
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    vpdn group PPTP-VPDN-GROUP accept dialin pptp
    vpdn group PPTP-VPDN-GROUP ppp authentication pap
    vpdn group PPTP-VPDN-GROUP ppp authentication chap
    vpdn group PPTP-VPDN-GROUP ppp authentication mschap
    vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
    vpdn group PPTP-VPDN-GROUP client configuration address local SS
    vpdn group PPTP-VPDN-GROUP pptp echo 60
    vpdn group PPTP-VPDN-GROUP client authentication local
    vpdn username xxxx password *********
    vpdn enable outside
    dhcpd address 192.168.0.2-192.168.0.33 inside
    dhcpd lease 3600
    dhcpd ping_timeout 750
    dhcpd auto_config outside
    dhcpd enable inside
    terminal width 80
    Cryptochecksum:b1e039a239a03680c43302546ee79164
    : end
    [OK]

    Thanks again, Walter, I guess I need another lesson.
     
    Hank Zoeller, Jan 21, 2006
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.