VPN access thru PIX 501

Paul.Lane · ‎07-17-2003

I have setup the PIX so I can VPN from the road and access my internal network. I am using the Windows XP client. I added a WINS server on the network also for name resolution. I am able to authenticate thru the PIX with no issues. However I cannot access any of the servers. I can't ping the gateway [PIX internal interface]. Below is a copy of my config, could you let me know what I'm doing incorrectly.

: Written by enable_15 at 23:18:15.136 UTC Tue Jul 15 2003

PIX Version 6.3(1)

interface ethernet0 auto

interface ethernet1 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password encrypted

passwd encrypted

hostname homepix

domain-name

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol ils 389

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

names

access-list 101 permit tcp any host xx.xx.xxx.xx eq pptp

access-list 101 permit gre any host xx.xx.xxx.xx

access-list 102 permit ip 192.168.1.0 255.255.255.0 10.10.10.0 255.255.255.0

pager lines 24

logging on

logging timestamp

logging trap informational

logging host inside

mtu outside 1500

mtu inside 1500

ip address outside dhcp setroute

ip address inside 192.168.1.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool vpdnpool 10.10.10.1-10.10.10.3

pdm location inside

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 1 interface

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 RADIUS protocol radius

aaa-server LOCAL protocol local

http server enable

http 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 inside

telnet timeout 5

ssh timeout 5

console timeout 0

vpdn group vpn_ext accept dialin pptp

vpdn group vpn_ext ppp authentication chap

vpdn group vpn_ext ppp authentication mschap

vpdn group vpn_ext ppp encryption mppe 40 required

vpdn group vpn_ext client configuration address local vpdnpool

vpdn group vpn_ext client configuration dns xx.xxx.xx.xxx

vpdn group vpn_ext pptp echo 60

vpdn group vpn_ext client authentication local

vpdn username password

vpdn enable outside

dhcpd address 192.168.1.2-192.168.1.33 inside

dhcpd lease 3600

dhcpd ping_timeout 750

dhcpd auto_config outside

dhcpd enable inside

terminal width 80

steve · ‎07-17-2003

Hi

I hope the following gives you some guidelines:

Microsoft's NetBios protocol allows file and printer sharing. Enabling NetBios across the Internet does not meet the security requirements of most networks. Further, NetBios is difficult to configure using NAT. While Microsoft makes this more secure using encrypted technologies, which work seamlessly with the PIX, it is possible to open the necessary ports.

In brief, you will need to set static translations for ALL hosts requiring access and conduits (or access lists in PIX Software 5.0.x and later) for TCP ports 135 and 139 and UDP ports 137 and 138. You must either use a WINS server to resolve the translated addresses to NetBios names or local properly configured LMHOSTS file on all your remote client machines. If using WINS, each and every host must have a static WINS entry for BOTH the local and translated addresses of the hosts being accessed. Using LMHOSTS should have both as well, unless your remote users are never connected to your inside network (for example, laptop computers). Your WINS server must be accessible to the Internet with the static and conduit commands and your remote hosts must be configured to point at this WINS server. Finally, Dynamic Host Configuration Protocol (DHCP) leases must be set to never expire, or better yet, statically configure the IP addresses on the hosts needing to be accessed from the Internet.

if you need any more info, I'll try and dig it out

cheers

Steve

Paul.Lane · ‎07-21-2003

Thanks.

l.mourits · ‎07-18-2003

Hi,

You will have to add the following commands:

nat (inside) 0 access-list nonat

access-list nonat permit ip any 10.10.10.0 255.255.255.0

These commands are required to prevent reponse traffic packets being translated

That should do the trick.

Since the pool you are using for the vpn clients is limited to just three adresses, namely 10.10.10.1, 10.10.10.2 and 10.10.10.3 you could also prevent just these three adresses in the access-list nonat. This can be done by the following commands:

nat (inside) 0 access-list nonat

access-list nonat permit ip any host 10.10.10.1

access-list nonat permit ip any host 10.10.10.2

access-list nonat permit ip any host 10.10.10.3

Without these commands the packets returning are being translated to the global interface address on the outside (I know, sounds stupid, but this is really the case)

This is what happens on your current setup:

When a vpn tunnel is established the client receives an address out the pool, this address is the address that is seen as the source address when the clients tries to reach an inside ip address. The inside system then replies to this source address. When the returning traffic comes in at the inside interface, the PIX does first looks if it is an established connection, after that it checks if there are any translation needed (and they are, because of the nat inside 1 command in your config). If translations are needed then translations are done. If no translations are neeeded the PIX encryps the packet, if it matches against the dynamic access-lists which is created at the moment the PIX establishes the vpn tunnel.

The nat (inside) 0 with access-list nonat commands prevent the returning packets from being translated.

Try it, and you will see :-)

Good luck and kind regards,

Leo

Paul.Lane · ‎07-21-2003

Thanks!