Re: PIX 501 VPN - I can ping but can't map a drive
- From: roberson@xxxxxxxxxxxx (Walter Roberson)
- Date: Sat, 21 Jan 2006 03:18:48 GMT
In article <43d18ddd$0$27069$c3e8da3@xxxxxxxxxxxxxxxxx>,
Hank Zoeller <NoSpamAllowed@xxxxxxxxxxxxxxxx> wrote:
[re-arranged to make the answers a bit easier to follow]
>PIX Version 6.3(4)
>"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.
Yes, udp 161 is the SNMP protocol; HP's monitoring service in particular
likes to use SNMP to talk to the printer.
>access-list inside_outbound_nat0_acl permit ip host 192.168.0.250 192.168.4.0 255.255.255.240
>nat (inside) 0 access-list inside_outbound_nat0_acl
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:
>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
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 ?
>static (inside,outside) 192.168.4.0 192.168.0.250 netmask 255.255.255.255 0 0
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.
>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.
>"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.
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.
>ip local pool SS 192.168.4.1-192.168.4.11
>vpdn group PPTP-VPDN-GROUP accept dialin pptp
>vpdn group PPTP-VPDN-GROUP client configuration address local SS
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...]
.
- Follow-Ups:
- Re: PIX 501 VPN - I can ping but can't map a drive
- From: Hank Zoeller
- Re: PIX 501 VPN - I can ping but can't map a drive
- Prev by Date: PIX VPN client-to-client routing: clever ways?
- Next by Date: Qwest Private Network & Pix
- Previous by thread: PIX VPN client-to-client routing: clever ways?
- Next by thread: Re: PIX 501 VPN - I can ping but can't map a drive
- Index(es):
Relevant Pages
|
|
