No translation group found for tcp src dmz1 to an inside address

I am not too sure why I am getting this error. I have my PPTP client authenticating beautfully. I have assigned 192.168.102.0 to the RRAS server, this is the address range assigned to incoming PPTP connections I have static routes setup on the RRAS server to the inside networks that go via the DMZ1 interface on the PIX I am getting the following errors

3|Mar 01 2007 15:54:22|305005: No translation group found for tcp src dmz1:192.168.102.2/1082 dst inside:PEWFP01/3389 3|Mar 01 2007 15:54:25|305005: No translation group found for tcp src dmz1:192.168.102.2/1082 dst inside:PEWFP01/3389 3|Mar 01 2007 15:54:31|305005: No translation group found for tcp src dmz1:192.168.102.2/1082 dst inside:PEWFP01/3389 3|Mar 01 2007 15:54:44|305005: No translation group found for tcp src dmz1:192.168.102.2/1083 dst inside:PEWFP01/3389 3|Mar 01 2007 15:54:47|305005: No translation group found for tcp src dmz1:192.168.102.2/1083 dst inside:PEWFP01/3389 3|Mar 01 2007 15:54:53|305005: No translation group found for tcp src dmz1:192.168.102.2/1083 dst inside:PEWFP01/3389

192.168.102.2 is the IP address assigned to my PPTP client

These are the static and global assignments on the PIX pix(config)# sh run | i nat nat (inside) 0 access-list no-nat nat (inside) 0 PEWDC02 255.255.255.255 0 0 nat (inside) 0 PEWEX01 255.255.255.255 0 0 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 nat (dmz1) 1 0.0.0.0 0.0.0.0 0 0

pix(config)# sh run | i global global (outside) 1 203.59.123.43 global (outside) 1 vpn.affoods.com.au global (inside) 1 192.168.100.200-192.168.100.220 netmask

255.255.255.0 global (dmz1) 1 192.168.1.50-192.168.1.240 netmask 255.255.255.0

I just am unsure on how to assign a translation group for the

192.168.102.0 network and where to apply it. The outcome I am trying to achieve is that any PPTP clients on the 192.168.102.0 network can access resources inside my LAN

Any idea's?

Cheers

Scott

Create a network object group listing the internal host IPs of that the PPTP clients are to be permitted access to. Create a network object group listing the 192.168.102.* addresses that can be assigned to the PPTP clients.

Add this to your no-nat ACL:

access-list no-nat permit ip object-group InternalServicesGroup object-group PPTPClientGroup

and add sysopt connection permit-pptp to your configuration to permit the PPTP clients to bypass ACL checking.

At the moment, when your inside hosts talk towards the DMZ, they are doing so via the nat (inside) 1 0.0.0.0 0.0.0.0 statement (except for PEWDC02 and PEWEX01 -- neither of which is the PEWFP01 host you were trying to reach in the log entry.) The way the internal addresses appear on the dmz is then controlled by the global (dmz1) 1 statement -- the '1' of the nat (inside) 1 policy matching the 1 of the global (dmz1) 1 . So the DMZ hosts are going to see the internal hosts as 192.168.1.50-192.168.1.240 .

But when the DMZ hosts try to initiate new connections towards

192.168.1.50-192.168.1.240 they will be forbidden [unless there is something special in the no-nat list that we haven't seen] because nat/global statements are one-way: they translate for higher security going towards lower security, and block for lower security going towards higher security. nat 0 statements that do -not- have an access-list clause are also one-way, blocking new connections from lower towards upper.

nat 0 access-list is the highest priority type of nat or static, and it *is* two-way: it *does* allow connections from lower security towards higher security provided that the access-group or sysopt connection statements agree that the traffic should be passed. For the other cases I outlined above, the access-group and sysopt statements won't even be consulted because translations are checked first.