305005 No translation group found ...

[jmondaca]

I get the log 305005 ("Translation group found for ....")only for two specific machines in my DMZ1 trying to connect to one specific machine (172.16.Z.Z (mapped)) that is in the inside interface.

My config is like this:

nat (inside) 1 0.0.0.0 0.0.0.0

nat (DMZ1) 1 0.0.0.0 0.0.0.0

global (DMZ1) 1 172.16.x.x-172.16.y.y

static (inside,DMZ1) 172.16.Z.Z 172.17.Q.Q netmask 255.255.255.255

All other computers in the DMZ1 connects to the same machine in the inside and have no problems (no logs at all)

The most strange think is that when I stop the MSSQL Server in this two machines I stop receiving this messages.

Thanks.

[mvoight]

Can you post the full PIX message for one of the addresses? What is the routing table of the server?

[jmondaca]

Here are some of the messages:

305005: No translation group found for udp src DMZ1:Omar/2612 dst inside:Itanium/1434

305005: No translation group found for icmp src DMZ1:Omar dst inside:Itanium

305005: No translation group found for tcp src DMZ1:Omar/2656 dst inside:Itanium/445

305005: No translation group found for udp src DMZ1:Omar/137 dst inside:Itanium/137

Both machines are Windows and the default gateway is the pix interface.

Thanks.

[mvoight]

The host names in the command do not help.

Is the address of Omar in the address range defined by the global statement? Is the Z.Z address below in the address range of the global statement?

global (DMZ1) 1 172.16.x.x-172.16.y.y

static (inside,DMZ1) 172.16.Z.Z 172.17.Q.Q netmask 255.255.255.255

It might also be an issue with the netmask of the pix interface.

[jmondaca]

Sorry about the names, but here are some answers:

The address of Omar IS NOT in the range of the global

The address 172.16.Z.Z (the mapped ip address of the server that is inside) IS NOT in the range of the global.

I only have this problem with this specific IP. I have other machines in DMZ1 with the same versions of SQL that connects to the same SQL sever in the inside and do not generate this log message.

Thanks.

[patrick.cannon]

Did you configure your sql server to use a restricted set of ports to go through the firewall for rpc?

What you are describing occured to me before I did that. It will require a reghack on the both servers. If you do the reghack in your dmz, then all servers in that dmz must have the reghack if they communicate with the sql server.

Technet article Q250367

[l.mourits]

Hi,

The answer to your problem is really simple. What happens is the following. Since you try to start sessions on interface DMZ to interface outside (lower to higher securitylevel) the PIX checks to see if any nat and/or global commands are in place.

In your case there is a nat 1 command, but no corresponding global command on the inside interface.

Because I think you do not want to use ranslation, you have to tell the PIX to do not try to translate the source adresses on this raffic by using the nat 0 command.

In your case the best way would be using nat 0 combined with an access-list. Here's an example how to configure this:

nat (DMZ1) 0 access-list NONAT

access-list NONAT permit ip

access-list NONAT deny any any

What happens with this config in place is that the PIX checks the access-list NONAt first to see if any matches do apply, and if they do, it does use the command nat 0 for these packets (in other words, it does not try to translate). If no matches apply, the next nat rule will be checked (in your case nat 1, used for outside connectivity).

Hope this helps and kind regards,

Leo Mourits

(please remember to use the rating-system)

[jmondaca]

Leo,

I try to start session on interface DMZ to interface INSIDE not outside, that is why I use an static to permit the DMZ users to access the server that is inside.

In any case I tried your solution and I have the same problem.

But, why this happens to only one machine that is in the DMZ when I have at least 20 other ones that do exactly the same without logs?.

Patrick,

I havent tried the regedit modification yet since the servers are in production.

Thanks.

[mvoight]

One issue regarding the first comment in the response:

"The answer to your problem is really simple. What happens is the following. Since you try to start sessions on interface DMZ to interface outside (lower to higher securitylevel) the PIX checks to see if any nat and/or global commands are in place. "

The messages that the original poster was seen were for DMZ to inside traffic, which would not require a NAT or Global statement.

[l.mourits]

mvoight,

You are correct that nat or global are not required for dmz to inside traffic. That is, if correct static commands to inside networks are in place !!!

Since correct statics are not in place on this particular config (as can be seen in the original post) and no translation is needed (which I still assume, but Patrick did not confirmed this yet) configuring nat 0 with access-list nonat would be a far more better way to configure then a static command (less cpu, no proxy ARP issues)

Since Patrick did not seem to have the correct static in place (otherwise, why on earth would he get the error message saying there's no translation group found?), and I assumed that no translation is needed, the better way to configure this is using nat 0 (supported since 6.2 from lower to higher securitylevel interfaces).

Okay, back to the case. Patrick, did you exec the clear xlate after configuring my recommendations? If no, this could be why you still had the problem.

Otherwise, could you post you complete config (passwords and real outside Ip's removed) to get into more depth here.

Kind regards,

Leo

[jmondaca]

Leo,

Here are some of the message logs:

305005: No translation group found for tcp src usuarios:192.168.150.47/1285 dst inside:192.168.151.16/445

305005: No translation group found for udp src usuarios:192.168.150.47/1352 dst inside:192.168.151.16/1434

The complete config is like this:

GSC# show run

: Saved

:

PIX Version 6.3(3)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 usuarios security90

enable password xxxx encrypted

passwd xxxxx encrypted

hostname GSC

domain-name FROZEN.NET

fixup protocol dns maximum-length 512

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

fixup protocol tftp 69

access-list inside permit ip host 192.168.151.11 any

access-list inside permit ip host 192.168.151.12 any

access-list inside permit ip host 192.168.151.16 any

access-list inside permit ip host 192.168.151.13 any

access-list usuarios permit udp any any eq domain

access-list usuarios permit tcp any any eq netbios-ssn

access-list usuarios permit tcp any any eq 445

access-list usuarios permit tcp any host 192.168.150.11 eq 2050

access-list usuarios permit ip any host 192.168.150.16

access-list usuarios permit tcp any host 192.168.150.12 eq www

access-list usuarios permit tcp any host 192.168.150.13 eq ftp

pager lines 45

logging on

logging buffered debugging

logging trap warnings

logging history emergencies

logging facility 16

no logging message 106011

icmp permit any unreachable outside

icmp deny any outside

icmp permit any unreachable inside

icmp deny any inside

icmp permit any unreachable usuarios

icmp deny any usuarios

mtu outside 1500

mtu inside 1500

mtu usuarios 1500

ip address outside x.x.x.x y.y.y.y

ip address inside 192.168.151.2 255.255.255.0

ip address usuarios 192.168.150.2 255.255.255.0

ip verify reverse-path interface outside

ip verify reverse-path interface inside

ip verify reverse-path interface usuarios

ip audit info action alarm

ip audit attack action alarm

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address usuarios

arp timeout 14400

global (outside) 1 x.x.x.x-x.x.x.z netmask y.y.y.y

global (outside) 1 x.x.x.xx netmask y.y.y.y

global (usuarios) 1 192.168.150.200-192.168.150.254 netmask 255.255.255.0

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat (usuarios) 1 0.0.0.0 0.0.0.0 0 0

static (inside,usuarios) 192.168.150.11 192.168.151.11 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.150.13 192.168.151.13 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.150.12 192.168.151.12 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.150.16 192.168.151.16 netmask 255.255.255.255 0 0

access-group inside in interface inside

access-group usuarios in interface usuarios

rip inside passive version 1

route outside 0.0.0.0 0.0.0.0 x.x.x.x 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

aaa-server GSCIAS protocol radius

http server enable

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt connection permit-ipsec

sysopt ipsec pl-compatible

telnet timeout 30

ssh timeout 5

console timeout 0

terminal width 80

: end

I appreciate your time in this problem and hope this helps to find out a solution.

Jorge

[l.mourits]

Jorge,

305005: No translation group found for tcp src usuarios:192.168.150.47/1285 dst inside:192.168.151.16/445

305005: No translation group found for udp src usuarios:192.168.150.47/1352 dst inside:192.168.151.16/1434

The message tells you that IP address 192.168.150.47 on interface usuarios is trying to connect to IP-address 192.168.151.16 on interfcae inside and no translation group is found. Allright, I will start with explaing the static command, cause I strat to believe that you do not correctly understand the static command.

Looking at this static command:

static (inside,usuarios) 192.168.150.16 192.168.151.16 netmask 255.255.255.255 0 0

What this one does is telling the PIX to proxy-ARP for every ARP request concerning IP address 192.168.150.11 on interface usuarios. Besides that the commands tells the PIX to translate the destination IP address for any traffic destinated for this IP and travelling to the inside interface.

Now, let's look at what you would like to happen when the device with IP address 192.168.150.47 tries to connect to IP address 192.168.151.16 on the inside. What you want is the PIX to first respond to the ARP request that 192.168.150.47 sends. This ARP request asks for the MAC address of the default gateway because the destination IP is part of another subnet (this is very basic knowledge, so I hope you'll get this). the PIX responds with its own MAC address and the packet will be send to the PIX. When the packet arrives it contains an IP header with SRC IP 192.168.150.47 and DST IP 192.168.151.16.

Then the PIX first looks if it is part of an existing flow. Since this is not the case the PIX checks if any translations do apply. In your config there is no matching static, but a nat 1 command is found on the usuarios interface

nat (usuarios) 1 0.0.0.0 0.0.0.0, but, since there is no corresponding global 1 command on the inside interface the PIX sends you this message that no translation group can be found.

Now that I 've seen you whole config I have a better understanding what you're doing wrong. Theres only one way to solve your problems (I think) and that is changing the static commands that you have in place in the following:

static (inside,usuarios) 192.168.151.11 192.168.151.11 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.151.13 192.168.151.13 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.151.12 192.168.151.12 netmask 255.255.255.255 0 0

static (inside,usuarios) 192.168.151.16 192.168.151.16 netmask 255.255.255.255 0 0

In this case the PIX will find a correct static translation and route the packet to the inside and your problem will be gone. One important thing in this solution is that you need to change your access-list on the usuarios interface as well, but this shouldn't be to hard for you.

Why would you translate the desination address anyway for traffic from dmz to inside?

Hope this helps.

Kind regards,

Leo

[brajesh.kumar]

Hi Jmondaca

Whatever i get from this config is that in DMZ(usuarios) u are using 192.168.150.* address with this config.

ip address usuarios 192.168.150.2 255.255.255.0

INSIDE(+)192.168.151.11 ---->192.168.150.11 DMZ(-){that is inside address 192.168.151.11 is accessible throught address 192.168.150.11 on DMZ side,but the problem is that the DMZ side has also same address renge 192.168.150.*.}

Therefore in defining access-list the destination and source address may be same!!!

From my point of view solution may be like this for DMZ to inside access.

static (inside,usuarios) 192.168.151.11 192.168.151.11 netmask 255.255.255.255 0 0

and access-list like ..

access-list usuarios permit tcp any host 192.168.151.11 eq 2050

access-group usuarios in interface usuarios

Thanks.

Brajesh

[mvoight]

Here are some of the message logs:

305005: No translation group found for tcp src usuarios:192.168.150.47/1285 dst inside:192.168.151.16/445

305005: No translation group found for udp src usuarios:192.168.150.47/1352 dst inside:192.168.151.16/1434

Here is the static:

static (inside,usuarios) 192.168.150.16 192.168.151.16 netmask 255.255.255.255 0 0

The client appears to be at 192.168.150.47

Why would it be trying to use the .151 address since there is static entry for the .150 address?

The host at 182.168.150.47 should be trying to connect to 192.168.150.16, but appears to be connecting to 192.168.151.16. It is possible the server's had a path that bypasses the PIX in order to get to the 150.x subnet?