1. Home
  2. Cisco Systems
  3. PIX501 driving us nuts...!

PIX501 driving us nuts...!

We are a group of young Chinese setting up a simple LAN with a few desktops and printers with one ADSL connexion.

ISP ADSL modem PIX501 LAN

Out of the box we setup the PIX501 using the startup wizard (via the Internet Explorer), we made only two changes:

  1. the IP address of the PIX501 (now 192.168.0.1) 2. the IP addresses for DHCP (now 192.168.0.101-109)

Of course we entered our username and password for accessing the ISP, as well as a primary and secondary DNS addresses.

The PIX501 gets a DHCP address from the ISP, no problem there.

SKYPE is immediately active and available without setting anything in the PIX501. :-) yeah, we can talk!

This is the stuff driving us nuts!:

Web (http) and email (pop3) requests from the inside (LAN) end up with nothing back, like when you have connexion to the ISP. WHY!!!

Finally below is the PIX501 config.

Thanks for any help you can give us!

Cheers from the Container Port Road (cpr) kids (no we don't live in containers, just nearby the road going to the container port) ... :-)

: Saved : PIX Version 6.3(5) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password 8Ry2YjIyt7RRXU44 encrypted passwd 2KFQnbNIdI.2K77U encrypted hostname cpr 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 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 pppoe setroute ip address inside 192.168.0.1 255.255.255.0 ip audit info action alarm ip audit attack action alarm 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 sip-disconnect 0:02:00 sip-invite 0:03: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 telnet timeout 5 ssh timeout 5 console timeout 0 vpdn group pppoe_group request dialout pppoe vpdn group pppoe_group localname cpr vpdn group pppoe_group ppp authentication pap vpdn username cpr password ********* store-local dhcpd address 192.168.0.101-192.168.0.109 inside dhcpd lease 3600 dhcpd ping_timeout 750 dhcpd auto_config outside dhcpd enable inside terminal width 80 Cryptochecksum:4c36e0fd8ec21602791ab9203f01b633 : end [OK]
Reply to
jjr
Loading thread data ...

-----------

Thanks Walter! The old router had an outside mtu value of 1472, we tried it and it didn't work. We went as low as 1372 with the same negative result. We are using the same ISP (HKNet).

Now the values for the PIX501 are:

mtu outside 1472 mtu inside 1500

We added two extra dhcpd lines:

dhcpd dns 202.67.240.222 202.67.240.221 dhcpd domain ciscopix.com

The issues remain, no email, no web stuff, just the "cannot find server or DNS error" message.

LAN side is working fine (i.e. printers, etc.).

C'est la vie!

Reply to
jjr

No by names (i.e.

formatting link
Outside ping doesn't work either and Skype is still performing well...

By default with the wizard you get the following access rules: source is inside:any destination is outside:any interface is inside (outbound) service is ip

Reply to
jjr

oh by ip address like: 202.67.240.89 instead of

formatting link
--no it's the same...

Reply to
jjr

OK........... . . . . . ! We'll start logging in the coming hours, right now we want to crush the PIX501 under heaps of containers and sink it in Honkgong harbour! Thanks again, results will be posted.

Reply to
jjr

In article , wrote: :We are a group of young Chinese setting up a simple LAN with a few :desktops and printers with one ADSL connexion.

:ISP ADSL modem PIX501 LAN

:This is the stuff driving us nuts!:

:Web (http) and email (pop3) requests from the inside (LAN) end up with :nothing back, like when you have connexion to the ISP. WHY!!!

:PIX Version 6.3(5)

Say, that's new -- I hadn't seen anyone mention 6.3(5) before. I've grabbed it now ;-)

:mtu outside 1500 :ip address outside pppoe setroute

That's probably your problem. pppoe has an 8 byte overhead, so you should configure your outside MTU to a maximum of 1492.

Depending on the ISP, you might find that you need to go smaller than

1492, possibly even as low as 1372 or so.
Reply to
Walter Roberson

In article , wrote: :Now the values for the PIX501 are:

: mtu outside 1472 : mtu inside 1500

:The issues remain, no email, no web stuff, just the "cannot find server :or DNS error" message.

What if you try to connect to the www sites by IP address?

Reply to
Walter Roberson

In article , wrote: :oh by ip address like: 202.67.240.89 instead of

formatting link
--no it's :the same...

I would suggest that it's time to start looking at the logging, and then after that to start with 'debug'.

logging on logging timestamp logging buffered debugging

After that, the command line command show log will show the last

20 or so log messages. If you have a syslog daemon around (such as Kiwi Logger), then add

logging timestamp logging trap debugging logging host inside LOGGINGHOSTSIP

This will tell the PIX to send copies of all the log messages to LOGGINGHOSTSIP where you have more chance to review them.

If the logs don't give any clue,

debug icmp trace

and then try the ping by IP address again.

You can follow this up with debug packet outside to see what's really getting to the outside interface. But that produces a lot of data, usually, so you will soon want to no debug all

Reply to
Walter Roberson

Pinging with an IP address (i.e. 82.15.137.41) works, we said it didn't work but it always worked (after changing the mtu to 1472). Our mistake!

Doing anything on the Internet that uses (canonic) names (i.e.

formatting link
doesn't work. So the DNS mechanism as set in our PIX501 is not working the way it should... :-(

We did the log stuff (see below).

We also tried to improve the behavior of the PIX501 by adding/improving the script as we also wanted to test the vpn client (untested yet):

object-group network cpr.org network-object 192.168.10.1 255.255.255.255 network-object 192.168.10.0 255.255.255.0 access-list inside_nat0_outbound permit ip any 192.168.10.192

255.255.255.192 access-list outside_cryptomap_dyn_20 permit ip any 192.168.10.192 255.255.255.192

nat (inside) 0 access-list inside_nat0_outbound nat (inside) 1 0.0.0.0 0.0.0.0 0 0

http server enable http 192.168.10.0 255.255.255.0 outside http 192.168.10.0 255.255.255.0 inside

crypto ipsec transform-set ***-***-***-*** ***-***-*** ***-***-*** crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20 crypto dynamic-map outside_dyn_map 20 set pfs group* crypto dynamic-map outside_dyn_map 20 set transform-set ***-***-***-*** crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map crypto map outside_map interface outside isakmp enable outside isakmp enable inside isakmp key *********_*** address 0.0.0.0 netmask 255.255.255.255 isakmp identity key-id cpr isakmp nat-traversal 212 isakmp log 10 isakmp policy 20 authentication pre-share isakmp policy 20 encryption ***-*** isakmp policy 20 hash *** isakmp policy 20 group * isakmp policy 20 lifetime ***** vpngroup batcastle address-pool VPNclient vpngroup batcastle dns-server 202.67.240.22 202.67.240.221 vpngroup batcastle *** vpngroup batcastle idle-time **** vpngroup batcastle password *********_***

When we access the Internet, using an IP address, we can surf within the boundaries of the web site.

The log entries are sort of boring, because they don't say much (for us):

Build dynamic TCP translation from inside 192.168.0.2/3142 to outside

202.67.***.***/1040 Build outbound TCP connection 101 to outside 207.171.166.57/80(207.171.166.57/80) to inside 192.168.0.2/3142(202.67.***.***/1040) Build dynamic TCP translation from inside 192.168.0.2/3143 to outside 202.67.***.***/1040 Build outbound TCP connection 101 to outside 209.237.237.101/80(209.237.237.101/80) to inside 192.168.0.2/3143(202.67.***.***/1041) 192.168.0.2 Accessed URL 207.171.166.57://api/toolbar?method ...etc. 192.168.0.2 Accessed URL 209.237.237.101://data/Fga03114 ...etc. TCP access requested from 192.168.0.2/3144 to inside 192.168.0.1/https TCP access permitted from 192.168.0.2/3144 to inside 192.168.0.1/https

etc. etc.

Why DNS isn't working the way it supposes to?

Reply to
jjr

PS: Please ignore some of the scripting above regarding the ip subnet

10, we already changed them to 0. We copied these "improvements" from an existing script found on the web and made the necessary modifs, such as ip subnet and vpn group statements. We can repost a clean list if necessary.
Reply to
jjr

Thank you Walter! We did too many cut and paste from other scripts without thinking, hoping that a small box like the PIX501 would just work... It's Friday morning here and after school we'll correct all the mistakes you pointed to us. We'll make it work! Cheers!

Reply to
jjr

:Doing anything on the Internet that uses (canonic) names (i.e. :

formatting link
doesn't work. So the DNS mechanism as set in :our PIX501 is not working the way it should... :-(

:The log entries are sort of boring, because they don't say much (for :us):

:Why DNS isn't working the way it supposes to?

The log entries you shows made no attempt to connect to anything for DNS. You should check to see what dns server your devices have received.

I see that you have configured dhcpd auto_config outside but I also see that the IP address you are going out with in the logs, 192.168.0.2, is not in the dhcpd address range you defined, 192.168.0.101-192.168.0.109, so 192.168.0.2 is not getting its IP via DHCP and so isn't getting it's DNS server set to whatever the ISP passes in.

Reply to
Walter Roberson

Hi Walter, to simplify our lives we killed all the fixed IP addresses for the desktops, they don't need one anyway. Only our printers have fixed IP addresses (and a wireless AP which has not been tested yet, but we can ping it). Everything (web and email) works fine... :-) ...as you said the DNS servers never saw our fixed IP addresses.

We have an old Cisco ATA186 which has a fixed IP address (192.168.0.199) and we lost the dial tone, meaning that the ATA186 is not "registering" with the PIX501. We use it for SIP telephony. There are two default entries for SIP: fixup protocol sip 5060 fixup protocol sip udp 5060 Did we miss something there? Should we bind the ATA186, somehow...?

Later we'll cleanup the mess we created by borrowing entries from other scripts and keep you posted. Many thanks!

Reply to
jjr

We have to do some homework regarding the PIX501, it's far more complex that the Netgear/Linksys router/firewall/vpn (out of the box) HW we have been playing with. Our goal is to have a clean config that we can understand and build cool stuff on the top of it.

We now are redoing a clean basic config and we'll post it for your review. With many thanks from the Container Port Road (cpr) kids!

Reply to
jjr

In article , wrote: :Hi Walter, to simplify our lives we killed all the fixed IP addresses :for the desktops, they don't need one anyway. Only our printers have :fixed IP addresses (and a wireless AP which has not been tested yet, :but we can ping it). Everything (web and email) works fine... :-) ...as :you said the DNS servers never saw our fixed IP addresses.

It's more like the other way around: the systems with fixed IP address have not been configured with a DNS server to use, so they don't even try. The systems that are DHCP'ing are getting the DNS server configured to whatever the ISP passed along when your PIX did the dhcpd autoconfig from the outside interface.

If you hard-configure your fixed-IP clients with a DNS server, they should be able to work.

Also, I have a memory of reading that you can set the DNS server IP on your hosts to be the PIX inside interface IP, and that the PIX will pass on the requests to the server it was told in the dhcpd autoconfigure . I am, though, not certain of this... I do not see any reference to it on a quick scan.

:We have an old Cisco ATA186 which has a fixed IP address :(192.168.0.199) and we lost the dial tone, meaning that the ATA186 is :not "registering" with the PIX501. We use it for SIP telephony.

Sorry, SIP is outside of my experience.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.