pix6.3 logging

hi, should be simple:

how can I see active connections being dropped on a pix Cisco PIX Firewall Version 6.3(4) without a syslog server. I read a lot about the pix cpu going up to 100% if you log on the terminal, but if I know source/ destination hosts, how can I see which rule is dropping which packet?

cheers, m

Reply to
sillymartin
Loading thread data ...

the PIX would only go to 100% if you are using the console in debug mode and it overwhelms to serial port... use telnet.

you can always turn on buffered logging to 7 and look at "sho log"... or "debug access-list" command.

Reply to
uNiXpSyChO

ok,turned on buffered logging: but when I do "show log", i only get :

Syslog logging: disabled Facility: 20 Timestamp logging: enabled Standby logging: disabled Console logging: disabled Monitor logging: level warnings, 5670 messages logged Buffer logging: level debugging, 0 messages logged Trap logging: level warnings, 4464833 messages logged History logging: level errors, 1400695 messages logged Device ID: disabled

and there is definitely traffic on this pix, what am i doing wrong?

also: when I do "debug access-list all" i don't get any results

thanks,

Reply to
sillymartin

Hi,

If I remember correctly the commands are logg on logg buff 7 term mon

This will show you the the buffered loggin on the fly. However, keep in mind that on pix the messages will come only on the first ssh connection.

Reply to
vsaxena76

logging is disabled. enabled it via "logg on"

Reply to
uNiXpSyChO

thanks, looking much better,

played around with buffer and monitor logging (different levels) and it seems I never see a permit, only deny...

set up: access-list traffic_in permit tcp any host 1.2.3.4 eq ssh static (apps-lan,outside) 1.2.3.4 192.168.191.101 netmask

255.255.255.255 0 0

problem: ssh packets never arrive at host. in logging I don't see a deny, so maybe the static entry doesn't work

how can I see a permit in logging,so I know for sure how far the packet gets

thanks, m

Reply to
sillymartin

try "debug pack apps-lan dst x.x.x.x" to see packet destined for that host... or change to "debug pack apps-lan src x.x.x.x" to see originating IP to see if your PAT/NAT isnt working.

Reply to
uNiXpSyChO

Hello,

on PIX looking at the packet is not the best way to troubleshoot because there are alot of other factors which may deny the traffic. If you are getting a hit on that acl that is enough to tell you that you are receiving the traffic destined for that host inside.

try checking the translation table 'sh xlat' and see if you have a translation slot for 1.2.3.4. Try ssh ing the host from the inside to test if ssh server is enabled (dumb but true in some cases) try to go out to the internet from that server. try to ping the server from outside on that address for this you need to enable icmp for that host inside.

-Vikas

Reply to
Vikas

the OP said he didnt see any denies. you would get a deny on a translation error as well. it might be easier to do "sho xlate | grep

192.168.191.101" or 1.2.3.4 on very busy PIXen.
Reply to
uNiXpSyChO

got it!

thanx, sho xlate showed an old (wrong) ip adress

with "clear xlate" it worked immediately.

and yes, I did do "write mem" before, (reboot would have helped too, I guess)

so have you guys seen this behaviour?

thanks again

Reply to
sillymartin

yes. if you change/add a static entry it is recommended to "clear xlate" to make it effective, but it also whacks current translations.

you can always use PDM (vomit) as well for simple tasks.

Reply to
uNiXpSyChO

you are right, the server's internal ip adress had been changed, still, when I did sh x-late this came up:

pix# sho xlate | grep 192.168.191.101 Global 1.2.5.5 Local 192.168.191.101

(this external adress was never mapped to the internal host, afaik it is not even a server that's alive also it doesn't appear in the Pix config anywhere else)

and after clear xlate (and one ssh connect) it showed correctly:

pix(config)# sho xlate | grep 192.168.191.101 Global 1.2.3.4 Local 192.168.191.101

so where did Pix get that 1.2.5.5 adress from?

thanks again

Reply to
sillymartin

check your NAT and static config. sho glob, sho nat, and sho static.

the outbound connection may pick up a global address from the pool and keep it but you may think you have it statically mapped. although a "static" translation should take precedence for inbound and outbound.

Reply to
uNiXpSyChO

of course you're right again,

its in one of my global pool:

global (outside) 2 1.2.3.4 -1.2.5.6 netmask 255.255.0.0

thanks again for your expert help.

Reply to
sillymartin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.