Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Hardcore PIX gurus only

Posted on 2004-04-24
13
Medium Priority
?
515 Views
Last Modified: 2013-11-16
Oks, This is for hardcore PIX firewall gurus. I have debugs enclosed in here
and I don't understand this behaviour of the PIX.
This has been taken with Kiwi syslog with level 7 traps (debugging level)

2004-04-23 15:41:59 Local4.Info 10.1.0.10 %PIX-6-305011: Built dynamic TCP
translation from inside:10.104.1.161/3753 to outside:208.228.217.20/5946

2004-04-23 15:41:59 Local4.Info 10.1.0.10 %PIX-6-302013: Built outbound TCP
connection 7906 for outside:149.10.221.98/80 (149.10.221.98/80) to
inside:10.104.1.161/3753 (208.228.217.20/5946)

2004-04-23 15:41:59 Local4.Error 10.1.0.10 %PIX-3-106011: Deny inbound (No
xlate) tcp src inside:149.10.221.98/80 dst inside:10.104.1.161/3753

2004-04-23 15:41:59 Local4.Info 10.1.0.10 %PIX-6-110001: No route to
149.10.221.98 from 10.104.1.161


When a dynamic translation & a connection was made to the outside, why is
the response from the public internet site at 149.10.221.98 being denied?

This is a funny thing going on in my network where any computer assigned to
static IP:10.104.1.161 cannot access this particular public website and
other users in the 10.104.1.0 subnet can access this site fine excepting for
this one IP address. A reboot of the PIX doesn't help either.

I would welcome other suggestions for debugging but I am most concerned with
the above debug and don't understand why the PIX things there is no xlate
when it just made one the previous second.

Thx in advance!

0
Comment
Question by:billwharton
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 3
  • +2
13 Comments
 
LVL 23

Expert Comment

by:Tim Holman
ID: 10917176
2004-04-23 15:41:59 Local4.Error 10.1.0.10 %PIX-3-106011: Deny inbound (No
xlate) tcp src inside:149.10.221.98/80 dst inside:10.104.1.161/3753

This error says inside to inside ?  Suggests maybe something funny going on with NAT ?
Does fixup http or no fixup http make a difference ?
Does clear xlate make a difference ?

What version of PIX is this, and could we see you config ?
0
 
LVL 11

Author Comment

by:billwharton
ID: 10919758
I thought of putting in only config totally related to this problem but decided to put in the entire config if you guys want to have a look at that. It's funny the PIX is receiving a packet from the inside to the inside and hence not able to route it. After all, it just made a NAT translation correctly in the same second.

Btw, this is my environment:
Alcatel Access switch --- Alcatel Core Switch --- PIX Firewall --- 1601 Router (T1 link)
I would also like to bring to your attention that this is happening only with one bad IP address: 10.104.1.161
If I change the machine's IP to 10.104.1.162, it can communicate perfectly with the Internet server.

Now, this can possibly mean a problem with the Alcatel switch mainitainingg some kind of funny cache but I would still like to investigate the PIX as much as possible.

pix# sh run
: Saved
:
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
access-list 80 permit tcp any host 218.116.217.3 eq smtp
access-list 80 permit tcp 166.206.67.146 255.255.255.254 host 218.116.217.5 eq pcanywhere-data
access-list 80 permit tcp 166.206.67.148 255.255.255.252 host 218.116.217.5 eq pcanywhere-data
access-list 80 permit tcp 166.206.67.152 255.255.255.248 host 218.116.217.5 eq pcanywhere-data
access-list 80 permit tcp host 24.186.210.105 host 218.116.217.5 eq pcanywhere-data
access-list 80 permit udp 166.206.67.146 255.255.255.254 host 218.116.217.5 eq pcanywhere-status
access-list 80 permit udp 166.206.67.148 255.255.255.252 host 218.116.217.5 eq pcanywhere-status
access-list 80 permit udp 166.206.67.152 255.255.255.248 host 218.116.217.5 eq pcanywhere-status
access-list 80 permit udp host 24.186.210.105 host 218.116.217.5 eq pcanywhere-status
access-list 80 permit tcp host 166.206.233.62 host 218.116.217.5 eq pcanywhere-data
access-list 80 permit udp host 166.206.233.62 host 218.116.217.5 eq pcanywhere-status
access-list 80 permit tcp host 166.206.233.62 host 218.116.217.11 eq 3389
access-list 80 permit tcp host 166.206.233.62 host 218.116.217.12 eq 3389
access-list 80 permit tcp host 166.206.233.62 host 218.116.217.13
access-list 80 permit ip host 166.206.233.62 any
access-list 80 permit ip host 14.115.214.208 any
access-list 81 permit udp 10.0.0.0 255.0.0.0 any eq domain
access-list 81 permit tcp 10.0.0.0 255.0.0.0 any eq www
access-list 81 permit tcp 10.0.0.0 255.0.0.0 any eq domain
access-list 81 permit tcp 10.0.0.0 255.0.0.0 any eq https
access-list 81 permit tcp 10.0.0.0 255.0.0.0 any eq ftp
access-list 81 permit tcp host 10.1.10.2 any eq smtp
access-list 81 permit tcp host 10.100.1.23 host 170.161.17.12 eq citrix-ica
access-list 81 permit tcp host 10.100.1.15 host 64.213.162.137 eq 5151
access-list 81 permit tcp host 10.104.1.9 host 170.161.17.12 eq citrix-ica
access-list 81 permit tcp host 10.50.1.89 host 64.213.162.137 eq 5151
access-list 81 permit tcp host 10.104.1.26 any eq smtp
access-list 81 permit tcp host 10.104.1.26 any eq pop3
access-list 81 permit tcp host 10.104.1.127 any eq smtp
access-list 81 permit tcp host 10.104.1.127 any eq pop3
access-list 81 permit tcp host 10.104.1.7 host 174.161.17.12 eq citrix-ica
access-list 81 permit ip host 10.104.1.70 any
pager lines 24
logging on
logging host inside 10.1.0.11 6/1468
mtu outside 1500
mtu inside 1500
ip address outside 218.116.217.2 255.255.255.0
ip address inside 10.1.0.10 255.255.0.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (outside) 1 218.116.217.20
nat (inside) 1 10.0.0.0 255.0.0.0 0 0
static (inside,outside) 218.116.217.3 10.1.10.2 netmask 255.255.255.255 0 0
static (inside,outside) 218.116.217.5 10.104.1.100 netmask 255.255.255.255 0 0
static (inside,outside) 10.1.0.0 10.1.0.0 netmask 255.255.255.255 0 0
static (inside,outside) 218.116.217.12 10.1.10.4 netmask 255.255.255.255 0 0
static (inside,outside) 218.116.217.13 10.104.1.12 netmask 255.255.255.255 0 0
static (inside,outside) 218.116.217.11 10.1.0.11 netmask 255.255.255.255 0 0
access-group 80 in interface outside
access-group 81 in interface inside
route outside 0.0.0.0 0.0.0.0 218.116.217.1 1
route inside 10.0.0.0 255.0.0.0 10.1.0.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
url-server (inside) vendor n2h2 host 10.1.0.11 port 4005 timeout 5 protocol TCP
url-cache dst 128KB
filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow longurl-truncate
snmp-server host inside 10.1.0.11
no snmp-server location
no snmp-server contact
snmp-server community ty_rw
no snmp-server enable traps
floodguard enable
telnet 0.0.0.0 0.0.0.0 inside
telnet timeout 60
ssh timeout 60
console timeout 0
url-block block 128
terminal width 90
Cryptochecksum:875b3f15853499342024c2b7e1417fea
: end
0
 
LVL 13

Expert Comment

by:td_miles
ID: 10923707
The obvious suggestion then is to remove the Alcatel switch from the equation and connect that PC with the IP address to the PIX via either a crossover or another switch. This will tell you pretty quickly if the Alcatel switch is involved at all. The only problem I see is making this happen, as I'm guessing this is a live network so you probably can't just unplug everything...
0
NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

 
LVL 23

Accepted Solution

by:
Tim Holman earned 1000 total points
ID: 10926445
6.3(1) had a funny problem with NAT, in that any NAT changes you made would only come into effect after a reboot.
Would this apply in this instance ?
0
 
LVL 11

Expert Comment

by:PennGwyn
ID: 10933288
Any chance that there's a static ARP entry for this PC somewhere, so that the switch is feeding incoming packets for that IP address back to the PIX?

0
 
LVL 11

Author Comment

by:billwharton
ID: 10933323
These bad IP's are different each time.

also, if there was a static ARP entry, it would continue to happen after a reboot of the Alcatel but the problem does get resolved after a reboot.
0
 
LVL 23

Expert Comment

by:Tim Holman
ID: 10933376
Maybe you have a duplicate IP address on the network ?  Does your ARP cache match up with the MAC address that you think should have this IP ?
0
 
LVL 4

Expert Comment

by:hawgpig
ID: 10934624
I agree with Tim...this is probably a duplicate ip address...
but I would also like to suggest that you check your subnetting in the 10.104.1.161 range.....
Is .161 part of the subnet that you are using???
If it is..... does the core switch know where to send it??
in other words is it included in the subnet.....
this error is indicative of a bad route in the pix...
the other thing you can try is tightening up your
inside route statements
route inside 10.0.0.0 255.0.0.0 10.1.0.1 1
is very broad...
I'm bettting the issue is either a bad subnet or a route in the core switch....
you could try a
debug icmp trace with the ip address to see where the packet is going...
type debug icmp trace
and then ping the outside address you are trying to get to and see what the result is...
post it here and I'll help debug...
my bet is you won't see the ping hit the pix....
if this is the case the issue is in the core switch...
Good Luck
0
 
LVL 4

Expert Comment

by:hawgpig
ID: 10934635
Oh btw.....I see you are running 6.3.1.....you may also be running into a bug....
GET OFF 6.3.1 CODE....
one of the most buggy, cisco produced....
Good Luck
0
 
LVL 11

Author Comment

by:billwharton
ID: 10934918
I appreciate all your comments uptill this time.

Can someone send me the bug id's for 6.3(1)
0
 
LVL 4

Assisted Solution

by:hawgpig
hawgpig earned 1000 total points
ID: 10939000
Bill,
   At last check, there were over 300 bugs in 6.3.1 code.....
(You really don't want to read through all of them...)
all had been fixed by 6.3.3...but it also has several bugs...over 100 if I remember right
not sure what the latest code is.....unless you are using a feature in 6.3 code I would downgrade to 6.2.3 instead....
If you are using a feature in 6.3 code upgrade to 6.3.3 or the latest 6.3 cod....if 6.4 is out...DO NOT USE IT...at least wait for the first revision.
call cisco and tell them you think you are running into a bug in 6.3.1 and ask them for a software upgrade...
If you have a smart net this shouldn't be a problem....if you don't they should still send you off to TAC to get an upgraded code......
Good Luck
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains the fundamentals of industrial networking which ultimately is the backbone network which is providing communications for process devices like robots and other not so interesting stuff.
Considering cloud tradeoffs and determining the right mix for your organization.
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses

610 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