Re: No translation group found for udp src DMZ1

cstepniewski · ‎06-23-2006

I'm trying to get a server in my DMZ to talk to servers on the inside. I created an ACL to allow for this, but I keep getting this: Jun 23 2006 14:28:18: %ASA-3-305005: No translation group found for udp src DMZ1:10.3.200.100/8111 dst INSIDE:10.3.1.201/389

----------------------------------------

Attached is my configuration. Any help would be nice.

Thanks

0r8it · ‎06-23-2006

Likewise...

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Security&topic=Firewalling&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1ddb86b8

If I find a solution, I'll let you know!

regards,

Gary

0r8it · ‎06-23-2006

A question for you- do you want to nat the dmz->inside traffic for these servers or not?

Gary

cstepniewski · ‎06-23-2006

Idealy, but I'm willing to allow direct access if you show me how ot do it. I think I've butchered my DMZ nat/static statements and I can't seem to straighten them out...

ph0enix · ‎06-23-2006

From what I understand PIX 7 allows you to set two interfaces to the same security level. Routing from a lower security interface to a higher sec. int. is not allowed by default. That's the whole point of having a DMZ.

cstepniewski · ‎06-23-2006

You are correct but the low to high security traversal is allowed by ACL's. Otherwise, how do you excpect to let people in to a mail or web server. Typicaly every interface is going to have a higher security than your outside interface.

0r8it · ‎06-25-2006

In order to allow a static translation from dmz to inside WITHOUT IP address translation, you would do:

static (inside,dmz) netmask 255.255.255.255

So, if the box on the inside that you want to appear on the dmz untranslated is 10.100.10.1;

static (inside,dmz) 10.100.10.1 10.100.10.1 netmask 255.255.255.255

Then, of course, you'll need an acl to permit the traffic you need between them. And an access-group applied inbound on dmz, eg

access-list dmz_access_in extended...

access-group in interface dmz

FWIW, I too am trying to find a way to allow a server (actually 2 servers, to be honest) in a dmz access to a group of servers in the inside. I'm not there yet.

What I have tried is:

-opening up the static to allow everything from the inside to the dmz (and vice versa, of course) and then locking the traffic down with an acl, viz:

static (inside,dmz) 10.100.0.0 10.100.0.0 netmask 255.255.0.0

and then applying my access-lists and groups.

This actually works, but seems to have had the unexpected effect of the PIX wanting to send anything it sees on 10.100.0.0/16 out to the DMZ. Strange. I'm still investigating.

I'm pursuing the possibility of restricting the mask, etc, just now, but to be honest I'm about to start reworking the config from scratch in the lab to make sure there's nothing causing an obvious gotcha.

HTH, anyway. If I have any success I'll let you know. I've asked the TAC to help to.

As an aside; a constant source of irritation at present is the fact that the Checkpoint boxes we are trying to migrate away from can do this stuff easily. I'm starting to develop a new-found respect for CP!

best,

Gary

0r8it · ‎06-25-2006

Chris, try this:

here's a chunk of config that will permit a group of servers (2) in the inside to communicate with your dmz without ip address translation.

You'll want to change the acl to meet your own requirements.

I've been testing this all day, and it seems to work fine. This is on 7.0.4. You'll note that I've also set up an inbound connection for smtp, and a general nat rule for web-type stuff.

----------------------------------------------------

hostname testpix

names

name (my pix'es external interface) outside-interface

name 192.168.168.12 sg-clust-master-dmz

name 192.168.168.11 sg-clust-slave1-dmz

name 192.168.168.13 sg-clust-slave2-dmz

name 10.100.10.0 inside-interface

name 192.168.168.1 dmz-interface

name 10.100.55.0 rsa-host-01-in

name 10.100.56.0 rsa-host-02-in

name 10.100.90.1 mailhost-in

name (another of my external ip's) www-ip-ext

!

interface Ethernet0

nameif outside

security-level 0

ip address outside-interface 255.255.255.240

!

interface Ethernet1

nameif inside

security-level 100

ip address inside-interface 255.255.0.0

!

interface Ethernet2

nameif dmz

security-level 50

ip address dmz-interface 255.255.255.0

!

object-group network sg-clust-group-dmz

network-object sg-clust-master-dmz 255.255.255.255

network-object sg-clust-slave1-dmz 255.255.255.255

network-object sg-clust-slave2-dmz 255.255.255.255

object-group network rsa-clust-group-in

network-object rsa-host-01-in 255.255.255.255

network-object rsa-host-02-in 255.255.255.255

access-list outside_access_in extended permit tcp any host outside-interface eq smtp

access-list outside_access_in extended permit tcp any host www-ip-ext eq www

access-list outside_access_in extended permit tcp any host www-ip-ext eq https

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq www

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq https

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq 5510

access-list dmz-in extended permit udp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq 5500

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

static (inside,outside) tcp outside-interface smtp mailhost-in smtp netmask 255.255.255.255

static (dmz,outside) www-ip-ext sg-clust-master-dmz netmask 255.255.255.255

static (inside,dmz) rsa-host-01-in rsa-host-01-in netmask 255.255.255.255

static (inside,dmz) rsa-host-02-in rsa-host-02-in netmask 255.255.255.255

access-group outside_access_in in interface outside

access-group dmz-in in interface dmz

route outside 0.0.0.0 0.0.0.0 (my next hop) 1

---------------------------------------------------

Whats happening is:

The 2 statics:

static (inside,dmz) rsa-host-01-in rsa-host-01-in netmask 255.255.255.255

static (inside,dmz) rsa-host-02-in rsa-host-02-in netmask 255.255.255.255

Do a non-nat translation into the dmz (and vice-versa.) So my rsa-host-01-in and rsa-host-02-in are seen in their untranslated form in the dmz, and anything permitted by my acl's will appear untranslated when they talk to the rsa group on the inside.

We tighten down by the application of my acls:

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq www

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq https

access-list dmz-in extended permit tcp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq 5510

access-list dmz-in extended permit udp object-group sg-clust-group-dmz object-group rsa-clust-group-in eq 5500

only the devices/services I want to allow access from dmz to inside can gain access.

Now our access-group:

access-group dmz-in in interface dmz

HTH- rate me if it does?

Gary

cstepniewski · ‎06-25-2006

Gary,

Thanks for the example. I'll be trying these suggestions out tonight and tomorrow morning. I will, of course, let you know how it works for me and rate you eight times if it does.LOL

Thanks again,

cstepniewski · ‎06-25-2006

Thanks for the input. Please let me know what TAC says. (That's my next stepp if this forum fails.)I'll be trying your suggestions out tonight. I'll let you know how it goes.

Thanks again for all the help...

cstepniewski · ‎06-25-2006

Here is a question for you guys, Why do I need the static (inside,dmz) 1.2.3.4 1.2.3.4 netmask 255.255.255.255? Shouldn't an ACL statement on the DMZ access list allowing traffic to the inside be enough? Shouldn't the PIX routing take care of it? Why am I getting the No translation group?

Thanks

0r8it · ‎06-26-2006

I think its because any traffic on PIX moving from low->high security levels needs a static. Thats basically its mechanism for permitting this kind of traffic.

Ordinarily, this would mean an IP address translation, as you generally (thought not always, of course) want to hide the IP address ranges used in your trusted networks.

I suppose the dmz->inside flow for many organisations is a special case. You may not want the traffic to be translated, so that entitites in both dmz and inside see the traffic in its untranslated form. There are good reasons for doing this.

However, as the traffic is still low->high (in that the instigator of the connection may well be in the dmz), you still need a static. PIX logic demands this. Hence, there's a 'special case' static, where you can specify a non-translated static. This is the confusing bit.

And to tell the pix to do this, you need to say:

static (high,low)

And then the relevant netmask for the devices/subnets/networks you want translated.

The acl is the limiter for the types of traffic and devices you need to talk to each other.

Apologies if I've explained any of this badly, I'm still getting my head around it myself.

HTH-

Gary.

BTW- have you tried this out yet, and are you still getting an 'No translation group' message?

cstepniewski · ‎06-26-2006

I seems to have worked. Now I get this:

Jun 26 2006 15:20:12: %ASA-6-302014: Teardown TCP connection 37191 for OUTSIDE:10.3.20.100/3268 to DMZ1:10.3.200.100/28096 duration 0:00:30 bytes 0 SYN Timeout

What is a SYN Timeout?

0r8it · ‎06-26-2006

Hi Chris, glad my suggestions worked. I was working through what sounded like a very similar problem to your own, so I was picking up things as I went along.

Anyway: you know the way TCP sets up connections, and the famous '3-way-handshake?'. There's a not-bad description here on Wikipedia:

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

The PIX is set to close any connections that only get to the SYN stage after a preset, configurable period of time, which in your case looks like 30 seconds. On my PIX, I think the relevant entries are:

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

Again, if anyone cares to tell me I'm wrong on this one, please feel free.

I think your PIX is receiving some half-built TCP connections from a device in the outside to a device in the dmz; at least, thats what your post suggests to me. I dont think its anything to worry about. In a real-world scenario, your PIX looks like it would guard against any attacks that use a flood of SYNs to overwhelm resources.

Good 'talking' with you again-

Gary