+ 0 Votes Reponse To Answer dl_wraith 1 year ago Thanks for the replies - that's a little clearer now. A third question that did occur: 3) Is the Comcast simply routing layer 3 or is it NATting the traffic to another address range? If you don't know but have access to the Comcast router you should be able to tell reasonably easily. The two commands I gave you sound scarier than they are. A quick 'n' dirty explanation is: Xlate is simply a 'translation' that the PIX holds in memory to facilitate traffic across the PIX's various interfaces. Once you've ENABLEd in the PIX, use SHOW XLATE to see what I mean. Once the PIX knows an address for a connection on each interface it holds it in memory and re-uses it as long as one side or the other is continuing to try and communicate. Using CLEAR XLATE empties the PIX of all these remembered translations essentially meaning each new connection has to be re-learned as it's requested. Any established connections are dropped and have to be retried to get through. As for the FIXUP, now I know your DNS is going out past the comcast I can tell you that it may help you. The fixup command I gave you essentially tries to 'fix' DNS protocol packets to a size of 1024. This is in case overlarge DNS queries (which Win7 can easily create!) are not making it across the PIX properly. I hope that makes things a little clearer. BTW, if you aren't getting ICMP responses via traceroute until really later in the hops then you aren't getting echo replies from a lot of intervening items. On the PIX you could try setting up an access-list associated with the inside interface and use the rule: access-list acl_inside permit icmp any any where 'acl_inside' is the name of the rule you create. That will allow the PIX to respond to ICMP packets. One word of warning - while 'permit ICMP any any' is a handy troubleshooting step, it's not a great idea to leave this open on OUTSIDE interfaces - leaves the PIX vulnerable to ping of death and similar DDoS attacks.