06-23-2006 12:50 PM - edited 03-09-2019 03:22 PM
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
06-23-2006 03:05 PM
Likewise...
If I find a solution, I'll let you know!
regards,
Gary
06-23-2006 03:09 PM
A question for you- do you want to nat the dmz->inside traffic for these servers or not?
Gary
06-23-2006 07:18 PM
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...
06-23-2006 03:36 PM
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.
06-23-2006 07:22 PM
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.
06-25-2006 02:38 AM
In order to allow a static translation from dmz to inside WITHOUT IP address translation, you would do:
static (inside,dmz)
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
06-25-2006 09:40 AM
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
06-25-2006 02:24 PM
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,
06-25-2006 02:20 PM
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...
06-25-2006 03:41 PM
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
06-26-2006 12:54 AM
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?
06-26-2006 12:30 PM
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?
06-26-2006 10:22 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide