cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
602
Views
3
Helpful
6
Replies

%PIX-3-305005: No translation group found

agurekian
Level 1
Level 1

Hi all.

We have a problem with PAT on a PIX-535 (Cisco PIX Firewall Version 6.3(3)132).

The first two PAT rules work well.

We configured a third rule (nat-id 3), and it seems like we are unable to link together the nat and global statement.

global (outside-X) 3 interface

global (DMZ-Y) 1 A.B.C.D

global (DMZ-Y) 2 E.F.G.H

nat (outside-X) 1 access-list acl_nat_x outside 0 0

nat (outside-Z) 2 access-list acl_nat_z outside 0 0

nat (DMZ-Y) 3 192.168.xx.128 255.255.255.224 0 0

Jun 10 12:07:06 192.168.xx.4 Jun 10 2004 12:07:06: %PIX-3-305005: No translation group found for tcp src DMZ-Y:192.168.xx.132/1935 dst outside-X:10.yy.zz.100/110

We tried also with an ACL in the `nat` line (the packets did match the ACL, since the counter increased), we tried with a single IP address instead of `interface` in the global line, we did `clear xlate` before every new trial.

Any idea?

Thank you very much in advance.

Ciao

Aram Gurekian

6 Replies 6

kagodfrey
Level 3
Level 3

Can you confirm that the security level on DMZ-Y is higher than that on outside-X ? i.e

nameif ethernet1 outside-X security10

nameif ethernet4 DMZ-Y security60

HTH

Kev

Hi Kev

Yes, DMZ-Y is higher:

nameif ethernet0 outside-X security0

nameif ethernet3 DMZ-Y security90

I wonder if you might be running into a bug with Bi-directional NAT... there is a Junked Bug on CCO:

CSCdz40337

Configuring bidirectional NAT breaks unidirectional NAT

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdz40337&cco_product=PIX+Firewall&fset=&swver=&keyw=305005&target=&train=

which kind of sounds similar - maybe try removing the bi-directional nat statement and clearing the xlate to see if it suddenly springs to life?

HTH

Kev

That sounds interesting, and we are investigating if this bug could be related to our problem...

Unfortunately, we cannot remove the bi-directional nat, because it is configured over production PIXes.

We will try that in a test environment ASAP.

Thank you very much

Aram

PS: from what I could understand, 'junked' means that we do not have to expect a solution anytime soon?

Yeah - according to CCO, junked is "Bug report is discarded because it does not describe a problem that requires changes to hardware, software, or documentation."... I think in microsoft speak you would term it as a 'feature'...

There was a suggested workaround on the bug:

Workaround:

For users on the external interface, which are NOT configured to use bidirectional NAT, a bidirectional static may be created which will allow the source ip address from the external interface to appear on the inside with it's own source ip address.

i.e.

static (outside, inside)

Looks like a bit of a fudge there, having to add extra config as the line you have added broke your previous config, but there you go. As you rightly say, always best to try this sort of thing in a non-live environment where possible,

Best of luck anyway

Kev

agurekian
Level 1
Level 1