PIX 501 fails to connect to ISP through wireless router

access-list name permit icmp any any echo-reply
access-group name in interface outside
this is to reply to incoming pings from the outside so looks like you are ok there. What else do you have in the acls? The sequence can be iportant also if you have a negative statement before hand.

All of my ACLs are permit statements (grouped by interface, starting with icmp). I assumed that the rest of the ports were blocked by implicit deny and didn't specify any deny ACLs (maybe I should, but for now I'm just trying to get this thing running)

No, you don't need the deny statements, I was simply questioning whether you had any in place. Tim makes a good point regarding the default gateway, the route inside is only needed to cover the subnets that the inside interface connects to (through an internal router/layer 3 switch/gateway etc.

First, thanks for all your comments!  Tim's corrections gave me the initial breakthrough: my server connected to the ISP, which was terrific.  I can resolve DNS and web sites, and log into my webmail through an https connection, so ports 80 and 143 get through.

However even before changing to this configuration (from an earlier config where the PIX made the PPPoE connection) I could not get icmp replies or ssh into my server from an external location, and I continue to have the problem now.  Also, since changing to this configuration, I can send mail but cannot receive mail from the Internet.  Nothing shows up in my maillog or on the PIX to explain the failure of Internet mail to reach the mail server.  I can telnet to mydomain.com on port 25 and mail works, and I can send mail to my yahoo address, but that's it.

Thankfully the problems are easier to diagnose than before, since part of my network now connects to my ISP from outside the PIX.  The PIX error log is finally showing some routing errors for icmp and ssh to point to the current problem.  I'll flesh out my network topology for this:
 
DSL ---->  Linksys Wireless Router ----->     PIX 501              -------> PC2 (192.168.x.2)
bridge          (eth0)         (eth1)                 (eth0)     (eth1)      --------> server1 (192.168.x.3, translated to 1.2.6.1)
mode           1.2.3.4        1.2.6.7                1.2.6.8   192.168.x.1
                                          |
                                          |
                                        PC1
                                      1.2.6.9

Here are the relevant entries in my current pix config:

global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 1.2.6.1 192.168.x.3 netmask 255.255.255.255 0 0
static (inside,outside) 1.2.6.2 192.168.x.4 netmask 255.255.255.255 0 0
access-group acl_out in interface outside
access-group acl_in in interface inside
route outside 0.0.0.0 0.0.0.0 1.2.6.7 1

access-list acl_in permit icmp any any
access-list acl_out permit icmp any any echo-reply
access-list acl_out permit icmp any any source-quench
access-list acl_out permit icmp any any unreachable
access-list acl_out permit icmp any any time-exceeded
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq ssh
access-list acl-out permit tcp any host 1.2.6.1 eq ssh
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq smtp
access-list acl_out permit tcp any host 1.2.6.1 eq smtp

pix1(config)# show route
        outside 0.0.0.0 0.0.0.0 1.2.6.7 1 OTHER static
        inside 192.168.x.0 255.255.255.0 192.168.x.1 1 CONNECT static
        outside 1.2.6.0 255.255.255.248 1.2.6.8 1 CONNECT static

Linksys wireless router Routing Table Entry List                 
Destination LAN IP       Subnet Mask             Gateway       Interface
0.0.0.0                        0.0.0.0                    1.5.1.1             WAN (Internet)
1.2.3.4                        255.255.255.255       1.2.3.4             WAN (Internet)
1.2.6.0                               255.255.255.0              1.2.6.7            LAN & Wireless
1.5.1.1                      255.255.255.255       1.5.1.1          WAN (Internet)

Here are the pix errors:
Deny icmp src outside:1.2.6.9 dst inside:1.2.6.1 (typ e 8, code 0) by access-group "acl_out"
Deny tcp src outside:1.2.6.9/1228 dst inside:1.2.6.1/22 by access-group "acl_out"

So, when an icmp or ssh connection to server1 is made from outside the PIX, at least on my LAN, the PIX thinks that server1's outside address resides on its inside interface.  Why?  My first suspect would be the static addresses, but then again I never understood the logic of that syntax - if the usual flow is from source to destination, it looks incorrect to write the rule as static(inside, outside) and instead the rule should be static (outside, inside) etc.  But it's even more confusing that the PIX routing problem occurs on some port numbers but not on others.




 

From inside your lan, you should be accessing the internal addresses and from outside your pix you should be using external public ip addresses to access it.

Cheers,
Rajesh

The fictional ip's in my network topology may have confused you, but the 1.2.6 series IPs are on my routable /29 network...when I ping or ssh to a routable IP on my network from a PC outside the PIX, the PIX error log is telling me that the packet is being routed to "inside" -- but it should not be necessary to route the packet to the inside interface on the PIX, which (192.168.x.1) is non-routable.  
It's possible that I don't understand how firewalls route packets, but as I see it, these packets are being routed to the wrong interface.
That's how I interpret these errors:
Deny icmp src outside:1.2.6.9 dst inside:1.2.6.1 (typ e 8, code 0) by access-group "acl_out"
Deny tcp src outside:1.2.6.9/1228 dst inside:1.2.6.1/22 by access-group "acl_out"

If my interpretation of the error is wrong, that might be good news, but sadly I think not.  

Internal to the PIX, there is no problem with icmp replies or ssh connections.
 
External to the PIX, icmp requests do this:
C:\>ping www.mydomain.com

Pinging www.mydomain.com [1.2.6.1] with 32 bytes of data:

Request timed out. (repeated three times)

Ping statistics for 1.2.6.1:

 Packets:  Sent = 4, Received = 0, Lost = 4 (100% loss)

The PIX is doing something wrong, and the problem precedes the current configuration.  When my PIX was running the PPPoE connection to my ISP, I couldn't get icmp replies or establish ssh connections to the routable IPs on my servers either.  

>>Deny icmp src outside:1.2.6.9 dst inside:1.2.6.1 (typ e 8, code 0) by access-group "acl_out"
Deny tcp src outside:1.2.6.9/1228 dst inside:1.2.6.1/22 by access-group "acl_out"

What the above means is that your access-list prevented it. So looking at the access-list acl_out, if you had applied in the other direction, then it would've worked.

which means, instead of access-group acl_out in interface outside

Try with;

access-group acl_out out interface outside
                               ^^^

Try the above for test case, in fact you don't need to complicate the acls like this. First of all, you don't need any acls on your inside but we'll come to that. Lets see if we understand each other.

Cheers,
Rajesh

Thanks, tried that, got this:
#no access-group acl_out in interface outside
#access-group acl_out out interface outside
Usage:  [no] access-group <access-list> in interface <if_name> [per-user-override]
# access-group acl_out in interface outside (better something than nothing)

Since my last post, I have lost outgoing smtp connections (now they don't work in either direction), and I can't make an http connection to www.mydomain.com from the outside, I guess the TTL expired.  

I can still access Internet web pages from behind the PIX.  I checked the PIX error log (set to warnings), and nothing appears in the log when there are connection attempts from outside my house.  The only errors that appear in the PIX log are from icmp and ssh connection attempts from PC1 (1.2.6.9) which is directly connected to my Linksys wireless router (outside the PIX).  

The ICMP errors on the PC1 client are the same as I detailed earlier from a UAF campus computer.  An SSH connection attempt from PC1 via putty displays server1.mydomain.com in the title bar, but the connection times out with a network error.   PC1 still can open the www.mydomain.com website in my Firefox browser, even after emptying the browser cache, and I can still telnet to www.mydomain.com on port 25 from PC1.

So the problem is not limited to the PIX, unfortunately.  But since no connections can be made from external locations into server1, it may become easier to troubleshoot at least that part of the problem.
Thanks for your patience, I wish this were easier.
 

Can you post your entire configuration and also mark where those pcs are present as you've been explaining ? Also mark the direction of traffic that is working & not working.

Cheers,
Rajesh

lol, yes please :)

'clear xlate' or a reboot might help

Leave out your encrypted passwords, domain name and usernames when you post up the config - that way, nobody can tell where it came from?  ;)

Ok guys, I'm posting an annotated copy of my pix config, with remarks and spaces added for clarity.
The config is cued to the network diagram I posted earlier, which I copy here (server2 is omitted, since it's down):

DSL ---->  Linksys Wireless Router ----->     PIX 501              -------> PC2 (192.168.x.2)
bridge          (eth0)         (eth1)                 (eth0)     (eth1)      --------> server1 (192.168.x.3, translated to 1.2.6.1)
mode           1.2.3.4        1.2.6.7                1.2.6.8   192.168.x.1  
                                          |
                                          |
                                        PC1
                                      1.2.6.9

PIX Version 6.3(4)
interface ethernet0 x.0full
interface ethernet1 x.0full
nameif ethernet0 outside security0
nameif ethernet1 inside securityx.0
enable password xxxxxxxxx encrypted
passwd xxxxxxxxxx encrypted
hostname pix1
domain-name mydomain.com
fixup protocol dns maximum-length 1024
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718.x719
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

no fixup protocol smtp 25  
//disabled to match the MX records check at dnsreport.com
//Mail from mydomain.com was being filtered as junk by some ISPs

fixup protocol sqlnet 1521
fixup protocol tftp 69
names

//Inside interface ACLs:
access-list acl_in permit icmp any any //any host can ping www.mydomain.com, or any host inside PIX
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq telnet //clients can telnet into servers
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq ssh //clients can ssh into servers
access-list acl_in permit udp 192.168.x.0 255.255.255.0 any eq domain //urls resolve
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq domain //urls resolve
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq www //all web pages accessible
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq https //all accessible
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq 8080 //added this for some urls
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq imap4 //this works

access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq smtp
// Internet mail usually goes out, although I get timeout warnings, since it's taking about
// 5 minutes for yahoo to respond to the client greeting.  For other than test mail, I've sent only
// one message recently and got a failed  delivery notification, with Name server timeout.
// No incoming mail from the Internet makes it in, with no errors in the PIX log or the maillog.
// A friend called in a rejection notice.

access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq pop3  
                                               //I can download my mail from server1 on a LAN client
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq ftp   //haven't tried this
access-list acl_in permit udp 192.168.x.0 255.255.255.0 any eq tftp  //or this either
access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq pptp  //not sure

access-list acl_in permit udp 192.168.x.0 255.255.255.0 any eq 631  
//network printing fails, but it's a CUPS error, since the CUPS log shows the broadcasts

access-list acl_in permit tcp 192.168.x.0 255.255.255.0 any eq aol  
//legacy from my kids, don't use it

access-list acl_in permit udp 192.168.x.0 255.255.255.0 any eq ntp  
//this works, but it's a few minutes behind

//Outside interface ACLs:
access-list acl_out permit icmp any any echo-reply     //server1 does not reply to external
access-list acl_out permit icmp any any source-quench  //icmp requests - icmp shows
access-list acl_out permit icmp any any unreachable    //Pinging www.mydomain.com [1.2.6.1],
access-list acl_out permit icmp any any time-exceeded  //then four timeouts, 100% packet loss

access-list acl_out permit tcp any host 1.2.6.1 eq pop3 //I'm using not using this now
//(I did once, with a relay server)

access-list acl_out permit tcp any host 1.2.6.1 eq smtp  //outgoing mail works, unless it times out
//no incoming mail from outside, and no port 25 connection attempts show up in the PIX error log

access-list acl_out permit tcp any host 1.2.6.1 eq imap4  
//incoming is not needed, and outgoing does not work, because IMAP works only when http connections
//are established. I can check my mail from PC1 off my Linksys router outside the PIX (see network
//diagram), but was unable to open a browser window to www.mydomain.com on the UAF campus
                                                 
access-list acl_out permit tcp any host 1.2.6.1 eq www
// incoming works, outgoing does not, i.e., I can access Internet web pages from behind the PIX,
// but http://www.mydomain.com is accessible only from PC1 off the Linksys router (outside the PIX),
// and not from other external locations, like the UAF campus

access-list acl_out permit tcp any host 1.2.6.1 eq https //same as www
access-list acl_out permit tcp any host 1.2.6.1 eq 8080  //same as www
access-list acl_out permit tcp any host 1.2.6.1 eq domain   //mydomain.com resolves from zoneedit,
//but since I'm running my own DNS servers, I left port 53 open on tcp and udp

access-list acl_out permit udp any host 1.2.6.1 eq domain //same as above
access-list acl_out permit udp any host 1.2.6.1 eq ntp    //this works, needs to be updated (4 minutes off)
access-list acl_out permit tcp any host 1.2.6.1 eq aol    //for my kids, will remove after Xmas

access-list acl-out permit tcp any host 1.2.6.1 eq ssh    
//no connections possible from outside the PIX: I get a network timeout from PC1 on the Linksys
//router, although server1.mydomain.com is recognized, and only a network timeout elsewhere

//server2 awaits a new power supply - if it were up, I would expect the same results
access-list acl_out permit tcp any host 1.2.6.2 eq pop3
access-list acl_out permit tcp any host 1.2.6.2 eq smtp
access-list acl_out permit tcp any host 1.2.6.2 eq imap4
access-list acl_out permit tcp any host 1.2.6.2 eq domain
access-list acl_out permit udp any host 1.2.6.2 eq domain
access-list acl_out permit udp any host 1.2.6.2 eq ntp
access-list acl_out permit tcp any host 1.2.6.2 eq aol
access-list acl-out permit tcp any host 1.2.6.2 eq ssh

pager lines 24
logging on
logging timestamp
logging trap warnings
logging facility 16
logging host inside 192.168.x.3
mtu outside 1500
mtu inside 1500

ip address outside 1.2.6.8 255.255.255.248    //routable IP for my /29 network
ip address inside 192.168.x.1 255.255.255.0  //see network diagram

ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400

global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 1.2.6.1 192.168.x.3 netmask 255.255.255.255 0 0
static (inside,outside) 1.2.6.2 192.168.x.4 netmask 255.255.255.255 0 0
access-group acl_out in interface outside
access-group acl_in in interface inside
route outside 0.0.0.0 0.0.0.0 1.2.6.7 1  
//thru Linksys router pppoe connection to ISP, see network diagram

timeout xlate x.00:00
timeout conn x.00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 x.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
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet 192.168.x.2 255.255.255.255 inside
telnet 192.168.x.3 255.255.255.255 inside
telnet 192.168.x.4 255.255.255.255 inside
telnet timeout 5
ssh 192.168.x.2 255.255.255.255 inside
ssh 192.168.x.3 255.255.255.255 inside
ssh 192.168.x.4 255.255.255.255 inside
ssh timeout 5
console timeout 5
dhcpd address 192.168.x.140-192.168.x.150 inside
dhcpd dns 192.168.x.3 192.168.x.4
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain mydomain.com  //disabled
terminal width 80
Cryptochecksum:xxxxxxxxxxxxxxxxxxxxx
: end
[OK]

I called my ISP, given that the PIX log failed to show any of my attempted connections from the UAF campus yesterday.  Apparently the ISP was making network changes at the same time that I was changing my LAN config, because I've had virtually no smtp connections since Saturday.  Clearly, adding a default inside route to my inside interface only aggravated the problem, so thanks Tim for that and for the guidance on icmp, and thanks Rajesh for your advice.

If my ISP did any network checks after making their own changes, I'm having difficulty understanding how they could fail to miss the fact that they are getting no icmp replies from the PPPoE gateway off my DSL.  I guess they expect their customers to notify them of network issues...this gets better: the tech support guy who answered the phone gave me no estimate on how long it will take to resolve the issue, but advised me to "reboot my DSL every 30 minutes or so to see if anything changes."  This is Fairbanks Alaska, but come on...the weather's been good this week!

The ISP gave me two new DNS server IPs, and I ran a traceroute against them and the old ones (which still should work), on a PC directly connected to my Linksys router (PC1 on my network diagram).  Both PC1 and the Linksys router are set to resolve DNS from my ISP, and all machines behind the PIX resolve DNS from my server1.  The router itself can resolve URLs on the Internet (working in the diagnostics window) but PC1 cannot.  Machines behind the PIX can resolve DNS (I'm writing from PC2).   All four traceroutes from PC1 show routing loops: hop 1 = the destination IP, followed by four hops, and the last hop = the destination IP again.  So I wait for the ISP to figure this out.  In the meantime, it has been very helpful to have this venue to check my own network settings, and it's been great that three of you have replied!  If any of you can shed light on these problems, I'd appreciate it, thanks...and of course if my PIX config can improve, I'm open to suggestions.  Now that the PIX is no longer running the PPPoE connection, I'd like to upgrade the IOS to Version 7, but must let the dust settle first.

>>reboot every 30 minutes ????

Thatz pathetic, C'mon how the hell can they say that, they don't care or what?

Cheers,
Rajesh

Yeah they don't...5 hours after they gave me a trouble ticket number, still no word (with the same traceroute results).  The tech support rep said that once a ticket has been submitted, it could take up to 24 hours for them to LOOK at the problem, and of course no word on how long it will take them to fix it.  If anyone out there in EE-land is interested in  starting an ISP in Alaska, I'm ready to switch.  

Wow, that is awful service but at least well done to you for getting to the bottom of it !! Sounds like you are a bit of a captive audience for this ISP though Sara.

Man... and I thought I had the worst service in India!

Cheers,
Rajesh

I think the problem with Alaska is it's too close to Russia, which leads to character traits that are bad for business: a mix of authoritarianism for the leaders and laziness for the rest of the lot, irrespective of individual competence.

My ISP finally had the courtesy to share with me that they do have a route between my assigned PPPoE static IP and my routed /29 network, and they mentioned the router that it resides on, which I had seen in trace routes from home and from the UAF campus.  The ISP believes that I cannot get an icmp reply or traceroute etc from www.mydomain.com because of NAT (or partly because of NAT, no one knows for sure).  I reset the Linksys router and did a traceroute to my ISP from it this morning, it looks good.  My ISP may be correct, so to debug this further I copy/flesh out my network diagram once more:

DSL ---->  Linksys Wireless Router ----->     PIX 501                        -------> PC2 (192.168.x.2)
bridge          (eth0)         (eth1)                 (eth0)     (eth1)                --------> server1 (192.168.x.3, translated to 1.2.6.1)
mode           1.2.3.4        1.2.6.7                1.2.6.8   192.168.x.1       --------> server2 (192.168.x.4, translated to 1.2.6.4)
                                          |
                                          |
                                        PC1
                                      1.2.6.9

The PIX is connected via a cross-over cable from its uplink port to a LAN port on the Linksys router (I tried connecting the two from LAN port to LAN port, which failed, although earlier, a straight-thru cable connection from the PIX uplink port to a Linksys LAN port did work).  
PC1 can ping the Linksys router and the outside interface of the PIX, and the Linksys router can ping the PIX outside interface, which is logical, since these devices are on the same subnet.  However, neither the Linksys nor PC1 can ping server1's virtual IP (1.2.6.1 above), which is also on the same subnet.  

server1 and server2's routable addresses are not associated with a device other than the outside interface of the PIX, so it's tough to debug.  So far, the PIX log yields only this clue:
Deny icmp src outside:209.112.144.90 dst inside:209.112.144.91 (type 8, code 0) by access-group "acl_out"
These codes can mean "source host isolated, net unreachable" or "echo, echo-reply," not sure.

My ICMP rules on the PIX are now correct (see earlier posts), and I have no iptables or equivalent running on my Linux servers.  
 icmp requests from PC1 are not leaving my LAN, so if I can't reach server1, my ISP can't either, and it's something I must fix.  Am I missing something?

I tried pinging server1's routable IP while logged on to the PIX more than once and got no response.  The PIX gets icmp replies from its outside interface, from the Linksys router (both interfaces), from PC1, and from the DNS servers at my ISP.  But it can only ping server1 on the inside (non-routable) address.  If the PIX can't see server1's outside IP, it's not surprising that no one else can either :(

I moved up the chain and found out that the PPPoE connection fails to properly connect or route to the routed /29 network on my LAN.  When the Linksys router was connected, PC1 could reach the Internet, but my ISP could not get icmp echo replies from PC1 (1.2.6.9): only the router (1.2.6.7) responded to icmp echo requests.  I suspected that the router was blocking incoming connection requests to other hosts on my LAN, so I connected a PC (on XP Home Edition) with two LAN cards on it, and with the XP firewall is disabled on all of its interfaces.  I connected this host (PC3) to my ISP via PPPoE, and here is my updated network diagram:
               
  DSL     ---->     PC3 (XP Home Edition running PPPoE)                
                           (PPPoE)         (LAN1)     LAN2: configured but not in use    
        IP Address:   1.2.3.4          1.2.6.7
                                                    |
                                               ---------
                                              |           |        
                                            PC1       PC2
                                          1.2.6.9    1.2.6.2
------------------------------------------------------------------------------------
Config detail on PC3:
               Gateway, PPPoE: 1.5.1.1         Gateway, LAN1: 1.2.3.4  
-------------------------------------------------------------------------------------

PC1 is an XP Pro laptop and PC2 is a Linux laptop.  Both can reach 1.2.6.7, and PC1 gets an icmp reply from 1.2.3.4, but neither client can reach the PPPoE gateway IP at 1.5.1.1 (this ip showed up in the Linksys router as the gateway and I don't see it on ipconfig /all on PC3, but in both cases it's the first hop on a traceroute to my ISP from here).  Since the LAN1 gateway of 1.2.3.4 is configured manually on PC3, and the PPPoE gateway of 1.5.1.1 is acquired automatically once the PPPoE connection is made, I'm not convinced that the two networks are properly routed to each other.  I've purchased another, more expensive router which will take two weeks to be delivered to Alaska, but as I wait, I need to understand what's broken, or the new router won't fix things either :(

ok, I'm back to the earlier config (I assume the pppoe dialup connection can't propagate to my ethernet NICs because it's point-to-point).

In response to your questions:
-yes, I can telnet to my mail server on port 25 from outside the PIX and the mail is delivered to my inbox.  However this only works on the part of my LAN that is outside the PIX, not outside the DSL in my home.
-I host DNS records for my 192.168.x.0 network, and zoneedit.com does the same for the 1.2.6.0 network (host names and aliases are the same for both networks)
-yes, my MX records resolve to 1.2.6.1:
C:\>ping mail.mydomain.com
Pinging mail.mydomain.com [1.2.6.1] with 32 bytes of data:
Request timed out.
Request timed out. etc
Again, from a PC on my LAN outside the PIX:
C:\>nslookup mydomain.com
Server:  ns1.myisp.net  //my DNS records are at zoneedit.com
Address:  1.5.4.7

Non-authoritative answer:
Name:    mydomain.com
Address:  1.2.6.1

I learned that my DSL can serve as a router, performing the same functions as the Linksys, so I changed the DSL from bridge to PPPoE mode - the only way my ISP would actually investigate the errors.  My ISP then restored access to my web and mail services, so I could make the same connections outside the PIX on my LAN as I could from the rest of the world, as of yesterday.  
The ssh problem was still there, so I checked the PIX log and found the same errors as before:
Deny tcp src outside:1.2.6.9/2359 dst inside:1.2.6.1/22 by access-group "acl_out"
I ran Ethereal on PC1 but found nothing unusual, and concluded that SSH requests from outside the PIX are rejected by an ACL I could not see.  I looked at the PIX again and noticed that instead of an underscore, I had used a dash.  So I fixed that, and now all is well.  I still don't understand why icmp requests are rejected, but I have another question open on PIX issues, so I'll close this one.