Solved

Ping works but tracert times out.

Posted on 2006-06-08
35
9,830 Views
Last Modified: 2013-12-07
Hi,
I have a situation where ping replies are acceptable, but tracert always timed out with astricks.
We are using a T1 that goes to a cisco 2524 router, which goes to a PIX 506 that handles the NAT.
All the computers on the network get the same results.  Wierd no?
SO..ping DOES works, BUT tracert DOES NOT work.
C:\>tracert www.google.com

Tracing route to www.l.google.com [72.14.203.104]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10    60 ms    51 ms    60 ms  72.14.203.104

Trace complete.

C:\>ping www.google.com

Pinging www.l.google.com [72.14.203.99] with 32 bytes of data:

Reply from 72.14.203.99: bytes=32 time=60ms TTL=246
Reply from 72.14.203.99: bytes=32 time=50ms TTL=246
Reply from 72.14.203.99: bytes=32 time=60ms TTL=246
Reply from 72.14.203.99: bytes=32 time=60ms TTL=246

Ping statistics for 72.14.203.99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 50ms, Maximum =  60ms, Average =  57ms

C:\>tracert 10.110.10.52

Tracing route to localcomputer [10.110.10.52]
over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  localcomputer [10.110.10.52]

Trace complete.

I would like to be able to use tracert to diagnose some performance issues mostly dealing with the WAN.  The inside pings are good and generally outside pings are also good, but certain web pages either can not display or load extreamly slowly.
As a matter of curosity, foxnews.com is particularly bad on all LAN computers also some microsoft.com pages.  Not that I care about fox news, but the client is in love with them for some reason, but i digress...sorry.
Please help
Laura
0
Comment
Question by:lizardqueen007
  • 14
  • 6
  • 5
  • +4
35 Comments
 
LVL 29

Expert Comment

by:mass2612
ID: 16867349
Hi,

Are you running ping and tracert from a Windows based machine?
0
 
LVL 29

Assisted Solution

by:mass2612
mass2612 earned 75 total points
ID: 16867362
Sorry - I should guess that you are using Windows since Unix is traceroute not tracert. Anyway both ping and tracert use ICMP so if that's open then you should be ok.  The unix traceroute uses UDP ports above 33000 though.

Have you tried running Netmon or similar when you sucessfully tracert an address and when it fails to google and take a look at the difference in the session info? I'm not sure on this one.
0
 
LVL 23

Accepted Solution

by:
Erik Bjers earned 150 total points
ID: 16867365
It is not unusual for some of the routers (hops) in a trace to fail to respond.  Most of these devices are configured not to respond to pings for security.

It is strange that you are getting all time outs from all the hops, I'm sure your internal routers/firewalls do not respond to pings, but most ISP routers will respond to a ping (tracert is the same protocal as ping and treated as a ping by network devices).

I would not be too concerned with these tracert results as long as you can get a responce from the last host.

eb
0
 
LVL 7

Assisted Solution

by:lukeca
lukeca earned 125 total points
ID: 16867387
Usually this happens because your gateway does not respond to pings.  A windows tracert just pings each device a packet hits on it's way to it's destination.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16867419
Thanks all,
I am using window machines.
The ISP recomended using tracert because I am having trouble with smtp going out of our mail server.  Maybe tracert will not reveal any useful information, but I would like to know why the icmp works for ping but not for tracert.  
0
 
LVL 23

Expert Comment

by:Erik Bjers
ID: 16867462
ICMP works for ping because it is only asking Google.com for a responce and google responds (this is also why your last hop in the tracert is working).  The hops are not working because the other hops (routers) may be configured not to responde to pings.

If you are having a problem with SMTP you may want to post another question with details on that problem.

eb
0
 
LVL 29

Expert Comment

by:mass2612
ID: 16867516
I have no idea if pathping works differently but you might want to try that tool also.

pathping google.com

Thanks for the info ebjers.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16867552
OK....
What I'm really trying to do is determine if the network performance problems are within our building or are the result of our ISP.  The ISP says everything is great on their end, but I've heard this before.  We have been having some apparent DNS issues and slow WAN times reported by the people in the office.  I have seen these pages loading very slowly myself on different work stations.  We have also had some smtp problems that may or may not be related.  I even suspected some sort of DoS, but I am no security expert.
Pathping yielded the following-not sure how to interperet.

C:\>pathping www.google.com

Tracing route to www.l.google.com [72.14.203.104]
over a maximum of 30 hops:
  0 admin.example.COM [10.110.10.25]
  1  ...
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           admin.example[10.110.10.25]
                              100/ 100 =100%   |
  1  ---     100/ 100 =100%     0/ 100 =  0%  admin.example.COM [0.0.0.0]

Maybe I'm going about this wrong. Is there a tool that can automatically ping or test in some manner the LAN and WAN for performance to localize problems?
Thanks Laura
0
 
LVL 12

Assisted Solution

by:GinEric
GinEric earned 100 total points
ID: 16868023
If you can't get to the first hop, which should be your server, or at least the first upstream at your ISP, then tracert does not have permission to get past your firewall.

You need to probably go into Windows and allow crucial things like snmp, snmp trap, find the place where your firewall keeps ping and tracert and make sure they're enabled.

Windows is aboslutely horrible, as are most firewalls, especially hardware ones, when it comes to completely stealthing off everything you want to do.  Unbeknownst to you, these firewalls are also preventing things like ICMP, IGMP, and other routing information that is simply slowing everything down with paranoiaware.

And false positives from scanning antiviruses further aggravate the problems.

Your NAT also has to allow ping and tracert commands from within your LAN forwarded to the outside WAN, or you will get timeouts when the responder refuses to answer, i.e., stealth mode.

You need to actually get Ethereal and see why the tracert, which is nothing more than a bunch of pings to each hop along the way, but using a differnet port, is not getting a response from your router.  I suspect there's either no path [Windows Server has disallow such commands] or the Cisco is in stealth for your LAN forwarders.


0
 
LVL 32

Assisted Solution

by:rsivanandan
rsivanandan earned 50 total points
ID: 16868204
The answer is already given by ebjers about why trace route has some 'Req timed out'. It is really *NOT* the problem.

What you can do is to check the real bandwidth you are getting on your edge routers that connects to this ISP. Elaborate more on what is your router and how are you connected to the ISP.

Go to the interface and see how many bytes out and bytes in which will give you an estimation of what the traffic looks like. May be it is the ISP or you have to look for more bandwidth.

Cheers,
Rajesh
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16868350
rsivanandan
thanks for the help-as I already said, it's a T1 connection using a cisco 2524 and a PIX 506
GinEric
The firewall is not on windows it's a PIX 506 and the issue is on all workstation regardless of OS
Thanks
0
 
LVL 23

Expert Comment

by:Erik Bjers
ID: 16869407
Configure the PIX and the router to respond to ping on the internal interface only (DO NOT ENABLE THIS ON THE EXTERNAL INTERFACE)
Create a rule on your PIX that will allow PING traffic to flow from the inside of your network out (DO NOT ALLOW INBOUND PINGS)

Also ethereal is great but I have found packitizer from network chemistry http://www.networkchemistry.com/products/packetyzer.php is easier to use and understand the results.  Also free like ethereal.

eb
0
 
LVL 32

Expert Comment

by:rsivanandan
ID: 16869499
Oh ok. What you can do is as I mentioned, just check out the data transfered which will give you an estimation of how traffic is going. 'Show int' will do the job. Post it here as well for us to take a look at it.

Cheers,
Rajesh
0
 
LVL 1

Expert Comment

by:KidsTrainingTeam
ID: 16872948
is pix  blocking? try bypassing pix letus know

regards
asim
0
 
LVL 12

Expert Comment

by:GinEric
ID: 16875894
What I said was that the router is not granting tracert execute privileges; it doesn't matter how it does this, what matters is that this firewall, pix or not, is blocking the tracert command.

tracert is not ping; therefore, just because ping works it does not mean that tracert will.

My tracert, by the Ethereal capture I just did, was sent out on ICMP and used port 1692 receive each query response from the DNS name server that is our main name server upstream.  Suppose the pix has this port turned off, then no response is the basic reply.  For each hop, TTL is increased by one, and what is expected is a timeout at each router along the way, mapping all the routers, basically all tracert does.  But not if ICMP or the query port 1692 at the source, the tracert sender, aimed at port 53 on its name server, up stream or not, is blocked; then you would get simply the timeouts and no report of who and why [the routers, time to live exceeded at each hop].

And no reply is stealth mode, or, the path does not exist, or, the path is broken.  Which is how every firewall fakes its stealth.

I believe your pix is not configured for tracert.  Barring that, that is to say, if it is configured properly, then Windows builtin firewall software and specific stealh permissions on ICMP, ping, and the handful of about ten control signals for DNS and routing, is blocking the command, even if on every single machine or on a single frontend server with the pix ahead of it, or not.

It's a simple tristate buffer scheme, on-off-indeterminant ::  enabled-disabled-stealthed

Port 1692 {a well known port}:
sstsys-lm       1692/tcp    sstsys-lm
sstsys-lm       1692/udp    sstsys-lm

[I can't believe people like info-techs-com posted everyone's email in their list of ports, but hey, who says you need a brain to be an infotech]  check IANA though, they do it properly, in text form.

[to prove just how useless google, dogpile, and all the others are, try a search using the basic scientific and educational method "definition sstsys-lm" or "sstsys-lm is defined as" or "sstsys-lm is an acronym that means" and you'll realise that this generation has no rules for definitions nor for the millions of acronyms; it just assumes everyone knows them; Bzzzzzzzz!  Wrong!

I had to do a define on wikipedia to figure out what this port was supposed to be, and, it turns out to be:

sstsys-lm - "Small Computer System Interface on Stream Protocl using Link Manager."

http://en.wikipedia.org/w/index.php?title=Sstsys-lm&action=submit

I have no idea whether or not that makes sense with your problem because the world has gotten absolutely ignorant on writing and how to use acronyms, the ebonics of the educated.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16878710
Ok sorry everyone
My question was perhaps vague or poorly constructed.  I did not ask if being unable to do tracert was "the problem".  I wanted to know why tracert did not work, but ping did.  I perhaps mistakenly thought that since they both use icmp they would be handled similarly by the PIX.
YES IT WAS THE PIX preventing the tracert!  This is not a surprise i am sure to most who answered.  I replaced the PIX with a linksys and was able to do tracert.
I am still wondering however why two things that use the same protocol are being treated differently.  I am new to PIX-very new and i am trying to get a handle on this ?#%z@*!! black box.   yeeeesh!
Anyway I'll try to sift through the barrage of responses and dole out points fairly-that's a monumental task in all by itself.
If any on can tell me exactly which part of the pix configuration is treating these icmp utilities differently, I would be appreciative-besides that it's probably academic.
Thank you all-Laura
0
 
LVL 7

Assisted Solution

by:lukeca
lukeca earned 125 total points
ID: 16878742
To be more clear, your PIX does not respond to pings, it has no problem passing them on though.  Google's IP does respond to pings, so when you ping google's IP directly it is google replying to your ping.  However when you do a tracert it pings every device a packet hits along it's way to it's destination.  Your PIX is your gateway, so that is the first device the packet hits, because the PIX does not respond to pings, the tracert never makes it past the first device.
0
Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

 
LVL 1

Author Comment

by:lizardqueen007
ID: 16878805
Lukeca,
To my understanding tracert is a series of pings with a limited lifespan.  Even though the pix did not respond, wouldn't the next device down the path respond?
0
 
LVL 23

Expert Comment

by:Erik Bjers
ID: 16879218
A tracert is basicaly a series of pings to each hop in a sequence to get to the end.  It appears that all hops in the chain to google from your system do not respond to pings (or one of them has an exceptionaly long delay) try tracert -w (milliseconds to wait) to give it more time to respond.  The fact that Google responded indicates that all firewalls and routers bettwen you and them pass tracert, even though they may not resopnd them self.

eb
0
 
LVL 12

Expert Comment

by:GinEric
ID: 16879842
Some "not true" 's:

"Your PIX is your gateway, so that is the first device the packet hits, because the PIX does not respond to pings, the tracert never makes it past the first device."  tracert pings everthing along the way, you said so yourself.  It does this by reading the the time to lives and limits the hops as well.  So, the first one goes out to one hop only, gets the gateway, increments the hops, and discovers if the next is the destination by the resolver.  If not, the process continues until it finds the queried name or IP, and if it hits a firewall, with no return, most tracert commands will state either firewall detected or go to the maximum 30 hops and end.

I gave the answer above; tracert is not ping, it uses a different port, sometimes a set of ports, one for ICMP, one for ping, and one for tracert or discover.

The pix probably did not have the proper port enabled, which is what a firewall does by default, stealths them, as in "no response."  The pix doesn't respond to pings only if configured that way.  Cisco has lots of examples of how to configure their software and routers, check their site.

Laura, the best I can say is browse Cisco because they have so many configurations it's unlikely anyone will know all of them off the top of their head.

Do you know how to interrogate the pix to ask it which ports are blocked, open, stealthed?


0
 
LVL 12

Expert Comment

by:GinEric
ID: 16879845
P.S.:  do the same for this "We are using a T1 that goes to a cisco 2524 router," which we all seem to have overlooked.

Cisco software on that one.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16879993
Thanks GinEric,
No I do not yet now how to interrogate the pix for open ports or even understand fixups, but I intend to learn-trial by fire.  Ebers said “The fact that Google responded indicates that all firewalls and routers between you and them pass tracert, even though they may not respond them self.", but I agree that something is not quite right with that logic since when I replace the PIX with the linksys, I do get several tracert responses from devices along the path.  It seems that the routers are responding, but for some reason the PIX is dropping the packets.  It is definitely the PIX preventing tracert responses and GinEric is probably right that it has to do with port assignments since they both use icmp.  I am able to telnet into the router and PIX, and I did have to reset the password on both devices by tftp so that's a start, but when I look at the Cisco's website data available it's daunting to say the least.  I did a show config on both devices, and now have some small insight into what they are doing.  I had to reconfigure the router from scratch however when I screwed up resetting the password, so besides the inside and outside IP, most everything else on the router 2524 is default settings.  I am waiting on some Cisco router books, because sorting through the Cisco website is tough.  I now have a book on ios in a nutshell, but which ios commands apply to which version is still unclear.  I can't even figure out if that 2524 can do NAT!  It's a simple question, but can not find the answer.  I do know that our smtp outgoing from the mail server seems to be getting dropped, but incoming mail is fine.  I think it has to do with the fixups, but what do I know???  We are also having intermittent page can't be displayed type issues, but the DNS seems ok.  All help is appreciated and thank you to all who are putting there 2 cents, since this discussion has been helpful.  I'm also looking in to the software recommended by Ebjers and GinEric.
0
 
LVL 32

Expert Comment

by:rsivanandan
ID: 16880015
GinEric,

  ejbers has it right. ICMP doesn't use any *PORTS*. Only those protocols who maintains a session needs ports and ICMP doesn't fit in there. It only uses 'type' and 'code', every tcp/ip stack knows this and that is why it works.

Two things.

1. Ping packet doesn't leave firewall, that is not correct. By default all the packets going out from in through PIX firewall is allowed (May it be icmp or tcp). So what the tracert output basically means is that all the networking devices across the path to google definitely understands the request but they are 'configured' not to reply back but then it allows it to go through. Otherwise, he wouldn't have gotten a reply back from google.

2. Again, there is NO port involved in ICMP. It doesn't use it. So as for the author there is nothing to worry about, almost everybody has the same scenario. Look at my tracert sample;

C:\Documents and Settings\Rajesh T Sivanandan>tracert www.google.com

Tracing route to www.l.google.com [66.102.9.147]
over a maximum of 30 hops:

  1     1 ms     2 ms     1 ms  192.168.0.1
  2    19 ms     2 ms     2 ms  202.142.67.1
  3     4 ms     3 ms     3 ms  202.142.94.1
  4    14 ms     3 ms     4 ms  202.142.88.1.zeeaccess.com [202.142.88.1]
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Look at it, I don't get a reply back at all! Does it mean I can't reach google ? wrong, I can. This is because my firewall doesn't entertain any kind of ICMP reply messages because I configured it so.



Also some when you replace the firewall with router, you said you get some replies, can you post that? There are different types of ICMP replies which can be blocked or allowed. But by default echo-req going out through the firewall is enabled and for that request, the reply will come to you.

if you want to allow everything on icmp just do this => icmp permit any any

0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16880035
Sorry rsivanandan ,
I can not post the results of the tracert while using the linksys instead of the PIX because I am not at the office, and I do not precisely recall all responses, but there were at lease ten devices reporting back.  But rsivanandan, I am not pushing the issue because I am "worried"-I am just trying to gain some deeper understanding of why similar seeming protocols are handled differently.  You have to admit that there are some inconsistencies in explanations to the question posed.  My goal is not to permit all icmp to come into my firewall, but to understand why Google’s response comes back through my firewall, but no other router's responses make it through.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16880072
rsivanandan,
If it helps I am using a windows machine to do the tracert.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16880076
rsivanandan,
Also I did not use any switches just tracert www.google.com
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16880100
rsivanandan,
You mentioned checking bandwidth.  What is the best way to accomplish this?  I have already tried dslreports, but how do I know what this circuit does under a real load?  It doesn't seem as though simple ping doctor type tools are adequate.
Any ideas?
laura
0
 
LVL 32

Expert Comment

by:rsivanandan
ID: 16880762
Laura,

  If you want to learn more about the behaviour, I suggest reading some good 'generic' tcp/ip books.

Like regarding the bandwidth, I already mentioned I believe. Go to the router to which the T1 is connected and take the output of 'show interface' and post it here.

Cheers,
Rajesh

 
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16882208
Rajesh,
i will post as soon as i have access to their network, probably a day or two- thank you
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16883456
Rajesh,
Thanks for the suggestion if I find the reason why the Pix blocks the tracert icmp but not the ping I will try to post so that you can learn the reason also.
Thank you
0
 
LVL 12

Expert Comment

by:GinEric
ID: 16884413
One other thing I found:  Start | Control Panel | Windows Firewall | Advanced

each and every Settings button, has a place for allowing all the basic DNS commands, from Allow Incoming Echo Request to Allow Outgoing Packet Too Big

I just turned them all on, thinking "what's the point in stealthing DNS???" before this, however, numerous things such as ping and tracert did not work even thought the Windows Firewall is turned off here.

It seemed to pre-empt other firewalls from working even when Windwos Firewall was turned off.

Oh, boy, do I know Cisco documentation is daunting!  Probably some dumb setting in the pix too, like one of the stealth settings, as shown in Windows Firewall above; you may have to set it to enable on both Server and Pix.

I got my tcp/ip books from Author Vent Cerf, who seems to have authored and be in charge of most routing for tcp/ip, probably a really good start.

Good luck Laura
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16884581
I'll check it out GinEric.  I'm in cisco pix boot camp hell because I'm under  the gun.  I'm going to try turning off some of the fixups for testing.  I believe that most of the people in here are right in that the tracert issue is not the problem, but it's still a mystery to me how the pix decides what to do and when.  I understand that icmp is connectionless and as to why the pix allows some icmp and not others is wierd.  I am questioning whether the firewall is even functioning correctly.  Our general seemingly unrelated network problems started about two weeks ago, with quite a few page can't be displayed issues that seem like dns, and now no smtp going to the internet.  Mail comes to the server and gets distributed to all the local computers and mail can be sent from inside to inside address, and inside ping times are good.  Also tracert works fine from one local computer to another.  When I replaced the pix with a linksys, I was hoping to get some insight into the problems, but the linksys performed worst than the pix even though I had the mail/web server in a dmz.  I had outside connectivity with the linksys router, but very slow.  I did end up resetting the cisco router in an attempt to reset the password about a week ago and now problems are worse.  i'm not sure if i've configured it correctly.  The only things that I configured are the inside ip address, outside ip address and where to route packets not within our LAN.  Anyway-I'll keep at it.
0
 
LVL 1

Author Comment

by:lizardqueen007
ID: 16919849
The solution was adding conduits to the firewall.
http://www.cisco.com/warp/public/110/pixtrace.html
and I issued the following comands to solve the problem:
conduit permit icmp host 99.99.99.99 any unreachable
conduit permit icmp host 99.99.99.99 any time-exceeded
conduit permit icmp host 99.99.99.99 any echo-reply
rsivanandan, I thougt you might like to know the reason, if it ever comes up again.
0
 
LVL 32

Expert Comment

by:rsivanandan
ID: 16919922
Hello friend,

 This is not new. If you check out the post Date: 06/11/2006 01:09AM PDT, I had mentioned it there. You aren't getting the root of the answer, but we've tried our best.

By the way, 'Conduit's are outdated and is removed from 7.0, so move onto access-lists.

Cheers,
Rajesh
0
 
LVL 12

Expert Comment

by:GinEric
ID: 16929667
lizardqueen007 I love it, the fact that you gave the cause and that you found it.  And the ensuing problems you had, resetting the password for the other router and stuff, is exactly why we replaced the entire frontend here with a U.S. Robotics Switch, an 8 port that just grabs whatever IP Address we give the computer cabled to it, and allowed ourselves the luxury of troubleshooting one server [or firewall, router, etc..] at a time, all the while keeping all other computers and servers online and working.

It had been suggested we buy some $2,500.00 Cisco router; I wasn't ready for that nightmare of putting all the eggs [servers and connections] in one basket, so I did some long research and finally bought the $47.00 8 Port Switch and now any router or firewall can do whateve it wants and it ain't gonna bring this network to a halt!

I figured it was the pix, and its configuration, only because tracert does use differnet ports and it was most likely that these ports were stealthed by default, either in the pix or in the Operating System, which in your case seems to be Windows.

I also dumped the ISP as Start of Authority for the various domains here and asked a friend what he would charge to be my registry name servers [another problem was I couldn't change the ISP's name server records] and it worked out nicely.  I changed the records myself, at our Registrar, then created the DNS records at DollarDNS.net and instantly the domains came up without a problem, even the various mail servers.  I could then ping and tracert them and all was well.  Well, after fixing a Windows problem with the required nVidia drivers.  The routers now can do their job and do it alone.  The firewalls can now do their job.  And everybody is independent of everybody else, which means, no single device can block the entire network from now on.

That Cisco has some pretty specific programming, even stateful packet inspection [just another headache in actuality, and will pretty much guarantee that some packets will get lost, be lost, or be blocked, even ones you don't want this done to].

I think you got to the root of the problem; pix was blocking packets by default.  By adding conduits, you turned it into a switch, even if they are "derecated."

What's an access-list, except "turn the firewall into a pass through switch."

Six of one, half a dozen of the other; anyway, thanks for the info Laura.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Article by: IanTh
Hi Guys After a whole weekend getting wake on lan over the internet working, I thought I would share the experience. Your firewall has to have a port forward for port 9 udp to your local broadcast x.x.x.255 but if that doesnt work, do it to a …
Some time ago I was asked to set up a web portal PC to put at our entrance. When customers arrive, they could see a webpage 'promoting' our company. So I tried to set up a windows 7 PC as a kiosk PC.......... I will spare you all the annoyances I…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now