I am using a PIX 501 between my internal network and the outside world. I have an AXIS web cam connecting to the the outside via NAT, Everything has worked perfectly until a couple of months ago when outside users could no longer connect to the AXIS. During my trouble shooting I found that PDM now reports my outside address as 172.27.xxx.xxx whereas it used to be 209.173.yyy.yyy which is what I had used in setting up the NAT. Using a couple of internet "what's my address" utilities reports my address as 209.173.yyy.yyy the same as it has always been. Changing the NAT to use 172.27.xxx.xxx does not work...neither address will now connect to the AXIS and my suspicion is that it might have something to do with Comcast implementing/testing IPV6 but I don't know enough about this subject to resolve the problem. Assuming it is in fact caused by something going on with IPV6, can the NAT problem be worked around in the 501 or is NAT now useless with it?
Any help in troubleshooting/resolving this problem would be much appreciated.
I'd be very surprised to find that this is connected to IPv6, although it may have something to do with something that happened at the same time as Comcast's deployment. I'm afraid that without the actual addresses, it's hard for me to traceroute/etc from this end. So I'll suggest that you do some standard IPv4 testing.
Get one of your friends that uses the AXIS on the phone, and put another computer running wireshark/tcpdump/whatever on the outside interface to your home network. Your internal computer, the one that runs the webcam, obviously needs to stay in place. Then have your buddy attempt to access the web cam. In theory, you should see a session start on the outside of the PIX; if in practical fact you don't - my guess - the issue is upstream. I would imagine you have a Dynamic DNS setup somewhere that gives a name to the webcam; is that giving the 209.173 address?
I would ask about CGN and port numbers, although I am pretty sure that Comcast is not (yet) deploying a CGN, given their public statements on the topic. I *will* point out that they enabled IPv6 on quite a number of residential-facing routers this past week, which they expect will result in several million sites starting to use IPv6 that two weeks ago were using only IPv4. You might want to think about enabling your webcam on IPv6.
If you do see the the session setup, repeat the test with your wireshark system on the "inside". When your buddy attempts the access, in theory you *should* see the corresponding "inside" attempt. If you don't, the problem is in the PIX; if you do, the problem is in the addressed system. It might be as simple as a problem in the local firewall.
Thanks for the reply. The 209 address is the IP Comcast assigns to my cable modem. It is a dynamic address but it has had the same one for 2-3 years, It did change back then but I was able to quickly determine that it had changed, updated the NAT with new address, and all was back to normal. At that time, the PDM reported the same outside address as any of the programs/utilities that detects and reports IP addresses...that's what has me so befuddled - I can't think of anything I can do that would change how PDM detects and reports the address. I was told by a person trying to help that the 501 was misconfigured, that the 172 address belongs to the private IPV4 space 172.16.0.0/12 and is not a routable address. I have not changed the configuration and that was confirmed by comparing an older saved configuration with the current running configuration.
Maybe the 209 address request from a user's browser makes it to the comcast router where it is changed to the 172 address which is what the 501 sees but now the NAT process is confused.
I 'm pretty much a novice at this sort of network troubleshooting so I may be using incorrect terms/confusing descriptions and I certainly have an incomplete understanding of it.
172.27 does in fact fit within 172.16.0.0/12, which is a private address space similar to 10.0.0.0/8 or 192.168.0.0/16. You can read about that at http://tools.ietf.org/html/rfc1918.
My daughter has a similar issue, which might be relevant. In her case, the router inside her home has an address in 192.168.1.0/24, and the upstream interface is in 192.168.7.0/24. It turns out that her DSL modem has a NAT buried in it - the provider doesn't implement a CGN, but the effect is the same. Verizon, when they started deploying CGN a few months ago, made an announcement; see if this sounds familiar:
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...