08-30-2010 12:50 AM - edited 03-11-2019 11:32 AM
Hi,
I am having some difficulty with configuring a PIX 501. I am very new to Cisco equipment and am sure that I am missing something very basic.
I have configured the device to the best of my abilities but it is still not working.
The PIX is sitting behind my DSL modem which is 192.168.1.1.
PIX outside: 192.168.1.111
PIX inside: 192.168.5.1 (running DHCP)
From the PIX I can ping WAN IP's (eg. google - 66.102.11.104) OK and also 192.168.1.1 (dsl modem), and also internal addresses on the 192.168.5.0 subnet. I cannot however from any devices on the 192.168.5.0 subnet communicate with the outside world.
I am sure there needs to be some form of NAT/PAT/something to allow 'inside' and 'outside' interfaces to communicate.
I have tried all kinds of combinations but with no success. If possible could someone review my configuration below and offer some advice?
Thanks in advance!
-Will
pixie# sh run
: Saved
:
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password aqfn/Uesjj5 encrypted
passwd aqfn/Uesjj5 encrypted
hostname pixie
domain-name living.local
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 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
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 192.168.1.111 255.255.255.0
ip address inside 192.168.5.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (outside) 10 interface
nat (inside) 10 0.0.0.0 0.0.0.0 0 0
route outside 0.0.0.0 0.0.0.0 192.168.1.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
http server enable
http 192.168.5.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
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd address 192.168.5.2-192.168.5.20 inside
dhcpd dns 192.168.168.101 203.12.160.35
dhcpd wins 192.168.168.101
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain living.local
dhcpd enable inside
vpnclient server xxx.xxx.xxx.xxx
vpnclient mode client-mode
vpnclient vpngroup living password ********
vpnclient username living1 password ********
vpnclient enable
terminal width 80
Cryptochecksum:8b9f9d5febad784d105320bda3532efd
: end
pixie#
08-30-2010 01:05 AM
Hi Will,
Try adding the command "fixup protocol icmp" and see if pings work. What happens when you to try to access google.com from a browser? Try accessing 74.125.19.147 as well (this is the IP address of google.com i found out using nslookup).
If you are able to access google using it's IP but not the name (google.com) then the issue is with DNS. Try adding "fixup protocol dns" as well on the PIX and see how it goes.
Let me know if this helps. All the best!!
Regards,
Prapanch
08-30-2010 01:10 AM
Hi Prapanch,
Tried adding both fixup lines you suggested. No change so far
If I try access google via hostname or IP in the browser it times out, same as if I try to Ping from a device.
I'm still thinking it is some kind of NAT/PAT issue rather than a DNS problem :-/
Thanks for the suggestion though
08-30-2010 01:07 AM
Base on the configuration, your internal user should be able to get to the internet.
I would try to "clear xlate" on the PIX, as well as enabling the icmp inspection "fixup protocol icmp error" if you are testing by ping.
From the internal PC, can you ping the DSL modem (192.168.1.1)?
Can you please check if dns resolution works fine for internal users, and if you can browse the internet, and default gateway for the internal users are 192.168.5.1.
08-30-2010 01:14 AM
Hi Halijenn,
Have tried "clear xlate", still no joy.
If I try ping 192.168.1.1 from an 'internal' PC it times out also.
DNS resolution also isn't working, I am guessing because it can't even access the external DNS server to attempt to resolve.
Unable to browse the internet
Thanks,
Will
08-30-2010 01:20 AM
Definitely not a NAT/PAT issue as the following will PAT everything to the PIX outside interface ip address which is responding to ping:
global (outside) 10 interface
nat (inside) 10 0.0.0.0 0.0.0.0 0 0
What is your internal test PC ip address, mask and default gateway? How is it being connected physically? Assuming that you are connecting via a switch, pls kindly make sure that they are connected in the same VLAN as the PIX inside interface. You can try to configure VLAN interface on the switch in the same subnet as 192.168.5.0/24, and try to ping out.
08-30-2010 01:24 AM
Hmm, I *though* I had done the NAT/PAT config correctly
Internal test PC(s) IP's are:
(statically set for testing)
IP:192.168.5.20
MASK: 255.255.255.0
GW: 192.168.5.1
(obtained via DHCP)
IP: 192.168.5.2
MASK: 255.255.255.0
GW: 192.168.5.1
Physically, they are both plugged into the back of the PIX 501 in ports 1 and 2 so this should limit any issues I am encountering.
So yes, still having problems :-/
08-30-2010 02:12 AM
Are you sure you need to configure this device as a vpn client for a vpn server? Is that actually working now?
You can try to do this in configuration mode, and it should disable the vpnclient functionality. This should allow the device to work as plain nat/pat firewall.
"no vpnclient enable"
Once you have done this, see if you can ping form inside 192.168.5.x pc to the default gateway of the firewall 192.168.1.1 .
You can also issue "debug icmp trace", and see the logs on the pix console if the pings are going through and getting response back.
Regards.
08-30-2010 02:49 AM
Hi edadios,
I am actually trying to set this PIX up to ultimately establish a VPN tunnel through to an ASA5505 that is currently running.
For now I have disabled the vpnclient as you suggested. Still not having any luck; cannot ping 192.168.1.1 from anywhere on the 192.168.5.0 subnet (with the exception being from the PIX directly).
08-30-2010 02:54 AM
Please try to do logging buffered debug, logging enable, or logging on, whichever applies, and also debug icmp trace, then check what logs you get when you try to do the ping through. You can paste show log output here, that may provide further information.
Regards
08-30-2010 03:09 AM
Ok,
Enabled logging, when I try to show the logs it doesn't really come up with much other than to say it is enabled.
The ICMP trace however was most interesting:
pixie#debug icmp trace
pixie# 28: ICMP echo-request from inside:192.168.5.20 to 192.168.1.1 ID=512 seq=37643 length=40
29: ICMP echo-request: translating inside:192.168.5.20/512 to outside:192.168.1.111/2
30: ICMP echo-reply from outside:192.168.1.1 to 192.168.1.111 ID=2 seq=37643 length=40
31: ICMP echo-request from inside:192.168.5.20 to 192.168.1.1 ID=512 seq=37899 length=40
32: ICMP echo-request: translating inside:192.168.5.20/512 to outside:192.168.1.111/2
33: ICMP echo-reply from outside:192.168.1.1 to 192.168.1.111 ID=2 seq=37899 length=40
34: ICMP echo-request from inside:192.168.5.20 to 192.168.1.1 ID=512 seq=38155 length=40
35: ICMP echo-request: translating inside:192.168.5.20/512 to outside:192.168.1.111/2
36: ICMP echo-reply from outside:192.168.1.1 to 192.168.1.111 ID=2 seq=38155 length=40
08-30-2010 03:21 AM
I don't think you did show log, or maybe the logging buffered debug has not been done, or the logging on/enable.
The inspect icmp should have done the trick.
You can try and setup an access-list that allows icmp back to the outside interface, and see if that will then make the ping work through.
access-list 101 permit icmp any host 192.168.1.111
access-group 101 interface outside
When time comes that you will need the vpnclient enabled again, ensure to enable split tunneling on the vpn server, and that should enable the client to get to the internet again in the clear. However, the vpnclient pix will have to be connected and working to the vpn server first before any other traffic can work through the pix.
I hope that helps.
Regards
08-30-2010 03:44 AM
So with the VPN, if I go down the path of having the "easyvpn client" is there any way to have split tunneling set on the PIX locally so that in the event of the tunnel not being established the local machines can still access the net?
If I was to configure the tunnel manually on the PIX rather than use the "easyvpn client" would the above be possible?
Thanks again for all your help!
08-30-2010 03:54 AM
For vpn client mode pix, the vpn has to be up, before any traffic will go through the firewall.
If this is not desirable, I suggest you configure the current vpn server ASA instead as lan to lan peer recieving a dynamic remote lan to lan peer, and the pix for a lan to lan setup, with the ASA as an static peer.
similar to this
Regards.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: