I have a few Pix 501s that connect over site to site VPNs. We use Orion NPM and I cannot add them for monitoring. I have been able to add remote routers that connect via site to site VPNs. I am assuming the security rules/NAT of the Pix are preventing this. The configuration of the remote Pix is attached.
Solved! Go to Solution.
You must add the outside interface address of the pix 501 to your interesting traffic.
access-list VPNHQ permit ip host
Then on the orion side you will need the mirror image of that....ex.
access-list VPNHQ permit ip host 172.16.30.19 host
and a nonat
Thanks for your assistance. On the Orion side, I have a 2800 router that is terminating all of the remote site to site VPNs. This includes both Pixs and 1800 routers. On the 2800, I dont have any NONAT ACLs. Just the one that specifies interesting traffic. At one point, we were doing split tunneling. Now we are not. I guess this means that NONAT ACL is not doing anything on the remote end? I tried adding the line to just the VPNHQ acl but still no luck. Thanks again for your response.
If you are not natting on the 2800 side then you dont need the nonat..your previous post didn't specify what was on the other end so I just threw that in there.
You need the interesting traffic acl on the 501 end and the mirror image on the 2800 end.
Post your 501 config and 2800 config if you need to.
This may help you too.
It's on ACL 123 that pertains to the remote Pix. I ran a debug on the 2800 while trying to add the device. I am seeing the SNMP traffic. It may not be getting back into the remote Pix or leaving the 2800 back to the Pix but I am seeing it at the 2800.
Oops, I saw that 24.x.x.x and went straight to acl 131.
Do a show cryto ipsec sa on the router and the pix and see if the sa is coming up.
SA is up on both sides. Seems like NAT/ACL is the issue. I can ping the outside interface of the remote Pix but when I do a trace, it seems that traffic is not going over the tunnel. We have multiple links out of our network and if i ping the outside interface, it goes out one link and if I ping any remote LAN address (10.46.0.0), it goes over the tunnel. That may have changed when we added the new lines to the ACL.
Looks like traffic from HQ (172.16.0.0) is being NAT'd and going out another interface if the destination is the outside interface on the remote Pix (188.8.131.52). This would explain why it is not working as the NAT'd IP is not in the ACL. I would actually prefer to monitor the inside interface of the remote Pix anyway and that traffic would definitely be protected by the tunnel. Just not sure if it is possible and/or how to do it.
That's not possible in pix 6. You need pix 7 (not available on 501) or an ASA. Otherwise the outside interface is your only option.
OK. Does it appear to be a routing issue then if traffic destined for 184.108.40.206 is not going out via the tunnel but going out a different link? Thanks again for your help.
It looks like it should be taking the time warner interface as that is your default route and you have a specific route to that address as well. Have you tried tearing the tunnel down and building it back up?
Have not tried tearing the tunnel down. We also have a 7606 router that the SNMP server is behind. From that router, if I do a trace to the outside address of the Pix, it goes out the other link instead of the TW link. But SNMP debugs in the 2800 show that the SNMP pakcets are getting to the 2800. I try to add the device while running the debug and they show up at the router.
I got it. Had to add a static route to the 7606. In addition to the ACL that you had me add, that did it. Thanks! How do I rate a post as a fix as you got it working and want to give you the credit you earned.
When I added the static route to the 7606, it came up via SNMP but I could no longer SSH to the outside interface of the Pix.
You may want to do policy routing to send only the snmp traffic from your snmp box to the outside interface. All other source addresses could take the other path.