The scenario:
A router receives (not advertises) the following routes:
10.1.1.0/24 via BGP
10.0.0.0/8 via EIGRP
The question:
Assuming admin distances, weights, etc. are at their defaults, will traffic desinted for 10.1.1.x use the BGP route because of the longer subnet mask (more specific...
You would control traffic using access-lists on the INSIDE interface of the each firewall. Let's say you have an IP range behind on firewall that is 192.168.1.0 and the IP range on the opposite end is 172.16.1.0. If you wanted to restrict only SMTP and POP3 going through the VPN tunnel, but...
No, upgrading the PDM does not reset the PIX to factory defaults, and you do not have to reconfigure the PIX after upgrading.
The first time you launch the upgraded PDM, it is going to add a bunch of 'PDM Location' statements in the PIX. These are used by the PDM to sort out which networks/IPs...
Upgrading the PDM does not erase your backup image. To upgrade the PDM, you will need to be running a TFTP server (not FTP, but TFTP). A free server is available from http://support.solarwinds.net/updates/New-customerFree.cfm?ProdId=52
Once you have a TFTP server running, and you have the PDM...
Last time I tried, my impression was that you couldn't do it by editing the crypto map. That was a while ago, however.
In any case, I did it by implementing outbound access-lists on the inside interface of each firewall. So, on the local subnet firewall, it might appear something like this to...
It depends on the version of your PIX OS. Newer versions (6.3(3) I think) allow you to use the static command to map from higher to lower. In addition to:
static (dmz,outside) <outside ip> <dmz ip>
add the following to map the public IP to your internal network:
static (dmz,inside) <outside ip>...
If you do as you described above, then there is absolutely no need for a firewall in the first place as you will be allowing all traffic from the outside to the inside - the reason you install a firewall is to PREVENT all traffic from the outside to the inside.
That said, you can provide access...
The 7.0 command is:
clear configure access-list <access-list name>
Just in case you haven't seen the doc, this is documented on Page 9 in the "Guide for PIX 6.2 and 6.3 Users Upgrading to Cisco PIX Software Version 7.0' document, which is actually a pretty good read overall...
Yes, that is exactly why. TCP is connection-oriented, and the PIX firewall keeps track of the connection state to allow ACK traffic back in (hence the term stateful inspection).
ICMP, on the other hand ititiates traffic from both ends. Your inside station initiates an echo-request, and the...
My gut reaction is it's a DNS issue. If you implement the access-list and your users have the ISP servers set for their DNS, DNS requests would be denied. You would need to add an additional line to the access-list permitting DNS services, like this:
access-list inside_out deny tcp host...
Not totally sure what you mean by "natively." If you mean "without having to add a router or other piece of equipment," then the answer is no. The PIX can have only one default route.
If your connections are T1, you can put a router in front of the PIX, then use BGP for two connections. We do...
There is a CiscoWorks Firewall/VPN manager (sold separately) that does what you need. If you want something that doesn't cost $$$, look at RANCID - http://www.shrubbery.net/rancid/ - which was created for routers/switches, but my understanding is it can be hacked for use with PIXes as well...
My initial guess: It's not in ISAKMP but in IPSEC. Tht would explain why a "show isakmp sa" looks good temporarily, then drops. Perhaps your IPSEC security association attributes are not matching up between the two devices, or the network lists on both ends do not match?
Did you set up the VLANs directly on the inside interface? If yes, then no inside routes should be needed. Did you define the first VLAN as "physical" in your commands? This tags packets with 802.1q
Also as an FYI, the use of VLAN 1 should be avoided. VALN1 is central to an attack known as...
Hmmm... Looks good to me... What do you get when you do a 'debug crypto isakmp' and 'debug crypto ipsec'? Do you at least get 'QM-IDLE' when you do a 'show isakmp sa' after trying to initiate the tunnel?
If you have a permeter router, apply an ACL to its serial interface to deny tcp 46200.
If you think it is an inside machine causing the issue, and you want to find it, place a packet capture on the inside interface. Here are the commands to do that:
access-list capture permit ip any any
capture...
It is available from Cisco, provided you have a service contract for the device. If you don't have a service contract, there is no legal way to download it.
The only thing I can think of has nothing to do with the PIX rebooting, but here goes: Do you have a DNS reverse-lookup record for the IP of the PIX outside interface (65.114.63.34)? HTTP performance can be intermittent without this. Cisco also has a doc that says the same thing...
Have you tried enabling the IPSEC Over TCP feature on your concentrator and VPN client?
On the concentrator, go to Configuration-Systems-Tunneling Protocols-IPSEC-NAT Transparency and enable IPSEC Over TCP, also specifying a port.
On the client, go to Options-Properties and select User IPSEC...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.