Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Troubleshooting PIX Firewall with Cisco expert Glenn Fullanger. Glenn is a customer support engineer at the Technical Assistance Center (TAC) at Cisco Systems, Inc. He is based in Melbourne, Australia. He is responsible for assisting customers in the AsiaPac region with high-level problems, specializing in the Security and VPN technologies. Feel free to post any questions relating to Troubleshooting PIX Firewalls. Remember to use the rating system to let Glenn know if you’ve received an adequate response.

Glenn might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through November 14. Visit this forum often to view responses to your questions and the questions of other community members.

170 REPLIES
New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello,

i have a PIX 520 running 5.1(4), equipped with four interfaces , RAM of 128 MB and flash of 2 MB.

I have three questions :

-i find out that each time a static translation from a Lower Security Interface to a higher security interface is created for a specific port (let say port 443) and once that static translation is opened , i am able to initiate from the same outside pc another session to the same destination( which resides on a higher security interface) on different port not listed in the static statement ( for example port 80 or 3389) ,normally the pix should not allow that !!! this way a lot of holes are security are opened

any clarification or turn around about this issue ?

2- Two questions REGARDING FALSH : i need to upgrade PIX 520 software to the latest software availabe; to do that the flash need BEFORE to be upgraded to 8 MB or 16 MB . the problem is i am not familiar with the PIX 520 hardware , i have opened the PIX 520 , but i could not find the 2MB flash , is that the circuit board card inserted in an ISA Slot on which there is DIP switches?

secondly once a new 16 MB is purchased does it require an activation or license before inserted in the PIX ?, or it is straight forward.

I hope that i was clear with my questions.

Regards

Ali

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hi,

For your Q1, if this is the case then it seems to be a bug, would it be possible for you to open up a case and follow up with the engineer to recreate the issue and file a bug? Besides, as per your part 2, you are seeking to upgrade the flash, so you can also try out a different code to see if you face the same issue or not

For Q2, I am also not sure about the hardware, but the easiest thing is to get the 16MB (8MB is not required, but 16MB) Flash, it will give you idea of the 2 MB flash, which you need to take out

Please keep in mind that once you upgrade the flash, you need to take out the 2MB flash card.

No! activation key change is not required. The same will work.

Thanks

Nadeem

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Nadeem seems to be butting in on my Ask the Expert event, but that's OK :-)

For your question 1, that doesn't sound right. Can you email me the config of the PIX, and the syslog output showing whne a new connection is opened that shouldn't be. Email address is gf@cisco.com

As for your flash questions, can't remember if it has dip switches on it, but it's a card in the PIX, should be the only one that has no ports or connectors on the outside part. You have to make sure you take this out BEFORE you put the 16Meg flash card in, the PIX won't work with both in.

You WILL need a new activation key though, regardless of what Nadem said. The serial number of the PIX is actually on the flash card, so when you upgrade it'll have a new serial number, and the activation key is also tied to the serial number. When you have it installed, just send a "sho ver" output to licensing@cisco.com requesting the same features as what you previously had.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

will the parameter "default gateway" of DHCP server be added in the future version of pix? Now we couldn't select, the default is the ip address of inside interface. It will be a problem if there are another subnets in the side of inside. We should set the default gateway be the address of one router.

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for your question.

There are currently no plans to implement this option in the PIX DHCP server. Keep in mind that the PIX can only assign IP addresses from a locally-configured subnet, so your statement about other subnets is not valid anyway. From the command reference (http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/df.htm#1025497):

--- snip ---

The address pool of a PIX Firewall DHCP server must be within the same subnet of the PIX Firewall interface that is enabled and you must specify the associated PIX Firewall interface with the if_name. In other words, the client must be physically connected to the subnet of a PIX Firewall interface.

--- end snip ---

The PIX DHCP server was never designed to be a fully functional multiple-subnet DHCP server. Since it can only issue IP addresses out of subnets that it has configured on one of its own interfaces, then assigning something other than itself as the default gateway would be a pretty rare instance.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hi,

I would like to ask you if you have received my Email tittled as jacob.zakhem@sps.net.sa regarding the PIX 520 configuration.

Thanks in advance for your reply?

Best Regards,

Ali.

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for sending me your config via email. I hope you don't mind but I'll answer you in the public forum so that others can learn the answer. In your email you wrote:

-----------------------------------------------

I have for example the following entry in the config file :

conduit permit tcp host 123.x.y.198 eq smtp any

let say I am using an outside pc with ip address 211.19.20.1 , from which I try to telnet my mail server 123.x.y.198 on port 25 ,the connection is ok , then from the same pc I try to telnet the same mail server on port 80 and it is ok also, despite the fact that port 80 is not opened to outside for mail server .

-----------------------------------------------

In your config you have the following (IP addresses changed for protection in lieu of security holes in this PIX):

conduit permit tcp host 123.x.y.198 eq smtp any

conduit permit tcp host 123.x.y.198 eq pop3 any gt 1023

conduit permit tcp host 123.x.y.198 eq www any gt 1023

established udp 0 0 permitto udp 0 permitfrom udp 0

established tcp 0 0 permitto tcp 0 permitfrom tcp 0

First off you are actually allowing www through to the mail server, so that's why you can get connected to it.

Second, your use of the established command has opened up a large security hole in the PIX. What you've said here is that if any internal host connects to an outside host, that outside host can then open up any connection to any port on that inside host. Not good. You don't actually need this since the PIX by default allows return traffic back through automatically. Remove these unless you really have a valid reason for putting them there.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello,

Thanks for your reply , i will try it then go back to you.

could you please send me code 5.1(4) plus the corresponding Boot helper on my email ?

Thanks

Ali.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello,

Two things to clarify:

1)these two commands

established udp 0 0 permitto udp 0 permitfrom udp 0

established tcp 0 0 permitto tcp 0 permitfrom tcp 0

are added by default and they were not configured.

any way i have tried to delete them from the config with :

PIX(CONFIG)#no established udp 0 0 permitto udp 0 permitfrom udp 0

PIX(CONFIG)#no established tcp 0 0 permitto tcp 0 permitfrom tcp 0

but i am still seeing both statements in PIX write terminal display.

How could i remove them or disable their effect?

Any insight on it ?

2) you are right www is allowed to outside ,but what about ports 3389 and 443? they are not opened to outside on mail server and he pix allow inbound

Thanks &Regards,

Ali.

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

From the 5.1 command reference, established command:

-----------------------------------------------------------------------------

Example:

established tcp 0 0

With this example, if something like the following exists:

static (inside,outside) 200.0.0.2 10.0.0.2

access-list acl_grp permit tcp host 200.0.0.2 eq www any

an attacker only need make a web connection to 200.0.0.2 and then they can make unrestricted connections using any protocol or ports.

--------------------------------------------------------------------------

This is exactly what you're running into, perhaps I didn't make myself clear in the first post. If you remove the "established" commands then the issue you're seeing should go away.

The "established" command is NOT in there by default, I just loaded 5.1(4) onto a PIX in the lab here and those commands did NOT appear in the config.

To remove them just try:

clear established

---------------------------------------

sv2-16(config)# sho est

established udp 0 0 permitto udp 0 permitfrom udp 0

established tcp 0 0 permitto tcp 0 permitfrom tcp 0

sv2-16(config)#

sv2-16(config)# clear est

sv2-16(config)# sho est

sv2-16(config)#

---------------------------------------

or:

no established tcp 0 0 permitto tcp 0 permitfrom tcp 0

no established udp 0 0 permitto udp 0 permitfrom udp 0

---------------------------------------

sv2-16(config)# sho est

established tcp 0 0 permitto tcp 0 permitfrom tcp 0

established udp 0 0 permitto udp 0 permitfrom udp 0

sv2-16(config)#

sv2-16(config)# no est tcp 0 0 permitto tcp 0 permitfrom tcp 0

Warning "permitto" port is 0 may introduce security risk

Warning "permitfrom" port is 0 may introduce security risk

sv2-16(config)# no est udp 0 0 permitto udp 0 permitfrom udp 0

Warning "permitto" port is 0 may introduce security risk

Warning "permitfrom" port is 0 may introduce security risk

sv2-16(config)#

sv2-16(config)# sho est

sv2-16(config)#

---------------------------------------

from config mode and see if they go away.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello,

I would like to thank you for your helpful assistance.

my case is solved once i cleard the both statements.

still one question , i am facing a random problem through my PIX 520 with the same config i have sent to you , that if someone ,and not all the time , try to retreive a large email ( around 2 Mb file size) from my secure mail server( on the most secured side) ,the transfer is interrrupted in the middle, if i put the mail outside the firewall , the problem disappears completely .

should i fine tune some parameters the PIX config ?

Thanks And Regards,

Ali

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Shouldn't really be any parameters you can fine tune for an ongoing connection. Read through the following and make sure you've done everything listed:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094459.shtml

Can you enable syslog and capture the output when the transfer fails:

logging on

logging buffer debug

sho log

Send me that output and another copy of yor PIX config please (to gf@cisco.com), include your original post in the email.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello,

i have treid to retreive some large emails and it was Ok,

basically the problem is random, in case this problem reappears again , could i send you an email at gf@cisco.com in the future ? or it will be restricted ?

Thank you so much

Ali.

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

That's my standard email address so you can always send email to it. I would sugget however, that you open a TAC case rather than email me directly since I may be on vacation, giving or taking a training course somewhere, be on sick leave, etc, etc. If you open a TAC case then you'll be sure to get 24x7 support.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Glenn,

I was looking to get further details of the handling of TCP sequence numbers by the Pix ASA. Could you point me in the direction of documentation discussing it in detail.

More specifically I'm looking to answer the following questions:

1) How the the Pix handle/account for out of order tcp segments coming back for an existing connection through the pix?

2) Does the ASA engine just add a random offset to the tcp seqence numbers at the start of every tcp conversation flowing through the pix?

thanks for your time,

Greg

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for your question.

The PIX will drop any out-of-order packets and it's up to the end host/apps to retransmit. Similarly, out-of-order fragmented packets are dropped.

TCP initial sequence numbers (ISN) are randomized as the connection is built through the PIX. This is to cover for some end hosts' TCP stacks that didn't create ISN's too well and allowed sessions to be hijacked. I obviously can't go into how the PIX randomizes them cause that would be a security risk (and to be honest I have no idea exactly how it randomizes them :-) but I'm pretty sure it has nothing to do with the original sequence number, it's an entirely new generated number for sure).

I can't find any great links on how ASA works to be honest. About the best I could find was this:

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/prod_brochure09186a0080091b2f.html

It's basically marketing fluff, sorry about that. Hope I've answered your questions though. If you have any more feel free to post them.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

what's the problem with the pix? www traffic is interrupted. The hosts in inside can visit internet sometime, but sometime couldn't. we can ping through pix when www didn't work. and other hosts that are not behind the pix can vist internet well at the same time. So it's pix problem.

The config is simple. the version is 6.3(1), the only problem we couldn't make sure is that there is a dhcp server. we really think dhcp affect the performance of pix, maybe there is a bug. Because in anohter case, pix 501, dhcp server, 6.3(1). Many notepads using dhcp client have the same problem as the above,but the host with a manual assigned Ip works well. It's really a little unreasonable, but the topo is so simple,the config is so simple. Only the dhcp is the new thing.

how to trouble? if we couldn't find reason using"show traffic' and 'show cpu usage", can that be the dhcp bug??

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for your question.

It's a litle hard to tell what's going on by your post. If you ever have connection problems through the PIX, the best bet to troubleshoot it is to turn on syslogging, the PIX will tell you exactly what's going wrong then. Do the following:

logging on

logging buffer debug

sho logging

I'll bet $10 you're running out of translations when the problem occurs. How many inside hosts are there? Do you have a PAT address configured, or just NAT translations? If you have something like the following:

global (outside) 1 x.x.x.1 - x.x.x.100

then change it to:

global (outside) 1 x.x.x.1 - x.x.x.99

global (outside) 1 x.x.x.100

The last address will be used as a PAT translation address when all the .1 to .99 addresses have been used. This will give you an additional 65000-odd translation entries for outbound traffic.

Failing that email me your PIX config to gf@cisco.com and the syslog output when the problem is happening and we'll get to the bottom of it. I doubt it's a DHCP issue, haven't seen anything like that. If you do email me your config please include your original post in the email so I now which problem I'm dealing with.

Hope that helps.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks very much.

we do have a NAT pool and a PAT address. That's a pix 525 UR, just about 300 users behind it.

I said it was unreasonable saying dhcp bug, we doubted it just because we sold many pixes and just the dhcp was the new thing.

we are trying to find if there are some virus, like something worm. we will set up logging, and use 'show xlate', 'show connection', 'show traffic', 'show cpu usage' to dig it out when that happen again.

Thanks again.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hello Glenn, I have three questions:

- How can I restrict to certain ip address to establish pptp connections to pix outside interface?

- I have configured a PIX PPTP VPN with a Windows 2003 IAS Radius server and don't work. Do you know if it is compatible?

- When you establish a pptp vpn connection with a pix outside interface, it connects from outside to inside, is it possible connect from outside to dmz and not inside?

Thanks

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for your question.

Hmmm, difficult one since the whole purpose of the "sysopt connection permit-pptp" command is to bypass all the ACL's and allow PPTP traffic straight in. You could put an ACL on the router outside the PIX stopping the traffic from reaching the PIX. You could also not use the "sysopt ..." command, but then you have to specifically allow all the PPTP traffic in your inbound ACL on th eoutside interface. Doing things like:

access-list inbound permit gre host x.x.x.x host

access-list inbound permit gre host y.y.y.y host

access-list inbound permit tcp host x.x.x.x host eq 1723

access-list inbound permit tcp host y.y.y.y host eq 1723

where x.x.x.x and y.y.y.y are the IP addresses you want to allow in. This acl is obviously in addition to anything you already want to have coming in on the outside interface like www and smtp, etc.

Not sure if IAS 2003 is compatible. Keep in mind that if you're doing PPTP encryption (MPPE) with authentication to a Radius server then the Radius server needs to send back a couple of attributes to the PIX. See here for details (there's a couple of sections specifically on Radius auth with encryption):

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080143a5d.shtml

You could also check the Radius server logs to see if the authentication is working OK, if that seems OK then it's probably the MPPE keys not being returned properly. Try setting up the users PC session to not do encryption, then try connecting, if that works then it's definately something to do with passing the MPPE attributes back to the PIX.

As for conneecting from inside to outside, it doesn't really connect to the inside per se. The PIX will see where you're trying to go and send the traffic out whatever interface it should go to dependent on its routing table. Usually this is the inside int. You can go to the DMZ just as easily, you just have to tell the PIX not to NAT the return traffic as it comes back through, as this is actually your problem. You'll have something like:

nat (inside) 0 access-list nonat

access-list nonat permit ip

All you need to do to talk to the DMZ is add the following:

nat (dmz) 0 access-list nonatdmz

access-list nonatdmz permit ip

If you don't want to be able to get to the inside at all, remove the inside nonat commands and that'll stop any connectivity to that interface.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hi Glenn,

I´m trying to upgrade a Pix Classic (ver 4.0.7) to 5.1.4. At first I tried to upgrade to ver 5.2.9 and found out that it is not possible.

It seems that ver 5.1.4 is not available. What do you recommend?

Regards

Fernando

P.S. I´m not sure if you are a rugby fan but long live the Springboks!!

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Fernando,

If you send me your email address (gf@cisco.com) I'll post the 5.1(4) code for you.

Go Wallabies (although I don't like our chances).

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Hi, Glenn

I've got a question regarding PIX firewall.

When we put different routing entries into the firewall routing table, the firewall will always try to match the closest one. In that case, we are able to exclude one or multiple small subnets (ex. 10.10.10.0/24) from a big one (10.0.0.0/8) to put into different interfaces while still leaving that big routing entry there unchanged. But it seems different for the "static" command. When I use 3 interfaces (inside, outside, DMZ) and static both 10.10.10.0/24 (from DMZ) and 10.0.0.0/8 (from inside) to outside interface, the firewall seems lost. Sometimes, it will even stop the connection. I consulted the local Cisco and it seems that the only solution is to put granular subnets on inside interface, which might be a nightmare depending on the previous IP address scheming. Is there a better way to solve this problem?

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Thanks for your question.

What you're running into is normal behaviour for the PIX. Keep in mind that when the PIX sends a packet through it, the first thing it does is check to see if there is an existing translation for it. If you have static commands then this sets up a permanent translation within the PIX, so the PIX will receive a packet destined for the 10.10.10.0 network, will se that it has a translation for 10.0.0.0 to the inside and will forward it out that interface. Yes, this can quite easily (and often) break connections.

The best way is to be more precise in your statics, so change your 10.0.0.0/8 on the inside to have only the exact subnets you want. This can get quite lengthy though as you've suggested.

Another way around it, although less preferred, is to order your statics similarly to how you would order entries in an access-list. Statics are read from top down, so put all your more precise statics at the top then the catch-all 10.0.0.0/8 at the bottom and you should be good to go. Of course if you ever change statics you need to make sure the order is kept correct, this may involve removing all statics and cut/pasting them back in in the correct order. sounds like a pain bu it's no different to what you currently have to do with acl's.

As an example, you would do the following:

static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

static (inside,dmz) 10.11.11.0 10.11.11.0 netmask 255.255.255.0

static (inside,dmz) 10.12.12.0 10.12.12.0 netmask 255.255.255.0

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

Note how the more specific ones are at the top.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

I have been having an issue getting a site-to-site VPN up and running I even have a TAC case open but it doesn’t seem to be going anywhere and the engineer hasn’t referred the case to a new engineer. Could you please have a peak at my VPN statements and maybe you can find something wrong. The VPN client is working fine it’s just the pix to pix is not working at all. There are no debugs working for ISAKMP or IPSEC for the site-to-site interesting traffic.

######################SITE 1########################

access-list inside_outbound_nat0_acl permit ip 172.16.1.0 255.255.255.0 172.16.2.0 255.255.255.0

access-list inside_outbound_nat0_acl permit ip 172.16.1.0 255.255.255.0 172.16.16.0 255.255.255.0

access-list vpn3000_splitTunnelAcl permit ip 172.16.1.0 255.255.255.0 172.16.16.0 255.255.255.0

access-list outside_cryptomap_20 permit ip 172.16.1.0 255.255.255.0 172.16.2.0 255.255.255.0

access-list outside_cryptomap_dyn_20 permit ip any 172.16.16.0 255.255.255.0

ip local pool remote 172.16.16.1-172.16.16.254

nat (inside) 0 access-list inside_outbound_nat0_acl

aaa-server partnerauth (inside) host WIN2K_DOMAIN censored timeout 5

sysopt connection permit-ipsec

sysopt radius ignore-secret

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map 20 ipsec-isakmp

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer X.X.X.34

crypto map outside_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map client authentication partnerauth

crypto map outside_map interface outside

isakmp enable outside

isakmp key censored address X.X.X.34 netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp nat-traversal 20

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

vpngroup vpn3000 address-pool remote

vpngroup vpn3000 dns-server WIN2K_DOMAIN

vpngroup vpn3000 wins-server WIN2K_DOMAIN

vpngroup vpn3000 default-domain censored

vpngroup vpn3000 split-tunnel vpn3000_splitTunnelAcl

vpngroup vpn3000 split-dns censored

vpngroup vpn3000 pfs

vpngroup vpn3000 idle-time 1800

vpngroup vpn3000 password censored

##############SITE 2################################

access-list inside_outbound_nat0_acl permit ip 172.16.2.0 255.255.255.0 172.16.1.0 255.255.255.0

access-list outside_cryptomap_20 permit ip 172.16.2.0 255.255.255.0 172.16.1.0 255.255.255.0

nat (inside) 0 access-list inside_outbound_nat0_acl

sysopt connection permit-ipsec

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map outside_map 20 ipsec-isakmp

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer X.X.X.194

crypto map outside_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map interface outside

isakmp enable outside

isakmp key censored address X.X.X.194 netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp keepalive 10

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

Cisco Employee

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Can't see anything obviously wrong with your config. If you say there are no debugs at all for this L2L connection, then that means the PIX either isn't seeing the traffic or it's not going out the outside interface.

Check that you don't have a route for the 172.16.0.0/16 network on either PIX pointing back to the inside interface. If you do you'll need a more specific route for the 172.16.1.0/24 or 172.16.2.0/24 subnet pointing out the outside interface. check you don't have an access-list applied on your inside interface that is denying the L2L traffic from even getting into the PIX. Check that both the 172.16.1.0 and 172.16.2.0 networks have routes (could just be the default route) for the remote network that points to the PIX inside interface and it's not routing off in some other direction.

Other than that I'd need to see the entire config off both PIX. You cna email them to me at gf@cisco.com, please include your original post so I know which question they're related to.

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

I've setup many VPN tunnels with PIX firewalls and a handful of times I've run into a similar situation where I knew the config was correct but phase 1 just wouldn't even seem to try to come up. The cure for my past experiences was to copy the config out (no sense wasting a good config), "write erase" the PIX, reboot the PIX, and then copy the config back in. If need be, do this on both sides.

I know it sounds crazy that this should work but it's done the trick for me a few times. Besides, it only takes a few minutes to try!

Good luck!

Rik

New Member

Re: ASK THE EXPERT- TROUBLESHOOTING PIX FIREWALL

Duane, your problem sounds like someting i fight with too. In my case its 2 1710 routers, but the behavior is the same: i had the lan to lan working, then i introduced the code for client access. Since then client access works fine lan to lan is impossible. i tracked it down to the IKE negotiation phase. The router does not use the adress I specified in the equivalent statement of your "crypto map outside_map 20 set peer X.X.X.194" , but tries to negotiate a dynamic one and that fails. Have you tried to remove the lines for the dynamic map and it worked then?

I posted that already to the user forum but got no "real" help on that, too.

cheers, christoph

158
Views
65
Helpful
170
Replies