Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

Accessing server on other network throught NAToutside

OK, I need some ideas how to solve this problem. This will be a quite brainstorming for you ;).

IP addresses are not real, but as in my real situation they are public IANA addresses :).

I will describe network situation:

PIX running PIXOS6.3 with three interfaces:

1.inside - 139.55.55.5/24 (sec-level 100)

2.outside - x.x.x.x (sec-level 0) - Internet

3.projectVLAN - 192.168.50.0/24 (sec-level 60)

On inside network is another subnet 139.55.56.0/24 behind router. PIX has route to this subnet

"route inside 139.55.56.0 255.255.255.0 139.55.55.254" (this is ROUTER2 IP)

Users from projectVLAN can access inside

servers using configured static(s) with ACLpermits on projectVLAN interface.

Problem is when users wants to access servers on subnet 139.55.56.0/24 trought static. Communication is not successfull, because traffic is not returning correctly. ROUTER2 on 139.55.56.0/24 is on other WAN location and do not have route to hosts on 192.168.50.0/24 throught PIX IP 139.55.55.5/24.

Therefore I have used static with conjuction "nat outside". Translates destIP and also sourceIP, of which ROUTER2 is aware of(know route to it). Connect to server(tested throught ping is now successfull), but all other communication from inside to projectVLAN do not pass(is blocked) with this syslog message on PIX:

"%PIX-3-305005: no translation group found for ICMP ..."

Here is short cut-out from config(I hope you will be able to see all needed stuff - sry for mistakes, this is not pasted but manually written - hope syntax is good :)

name 139.55.55.254 ROUTER2

name 192.168.50.200 NATaddforSERVER

nameif outside ethernet0 security-level 0

nameif inside ethernet1 security-level 100

nameif projectVLAN ethernet2 security-level 60

ip address outside 200.100.100.2 255.255.255.248

ip address inside 139.55.55.5 255.255.255.0

ip address projectVLAN 192.168.50.1 255.255.255.0

route outside 0 0 200.100.100.1

route inside 139.55.56.0 255.255.255.0 139.55.55.254

nat (inside) 5 0 0

nat (pVLAN) 10 192.168.50.0 255.255.255.128

nat (pVLAN) 20 access-list TEST outside

global (outside) 10 200.100.100.5 - 200.100.100.14

global (outside) 10 200.100.100.15

global (outside) 5 interface

global (pVLAN) 5 192.168.50.254

global (inside) 20 interface

static (inside,projectVLAN) NATaddforSERVER 139.55.56.10 netmask 255.255.255.255 0 0

access-list TEST permit ip 192.168.50.0 255.255.255.0 host NATaddforSERVER

access-group TEST in interface projectVLAN

Any good ideas are greeeaaatly appreciated =P.

If you solve this I will say that you are a quite network proffesional :))).

thx

1 REPLY
Hall of Fame Super Blue

Re: Accessing server on other network throught NAToutside

Think the problem is that you are translating all the projectVLAN servers to the inside interface IP address which is fine when you come from the projectVLAN to the inside. But when you try pinging from inside to projectVLAN the pix has no way of knowing which server on the projectVLAN you are trying to get to.

You have a couple of options.

1) The easiest, but probably not what you want, is to just advertise the 192.168.50.0 network on your internal routers but this is messy for your routing tables.

2) The second is to have static translations presenting the projectVLAN servers to the inside. You will need an unused NAT pool for these translations. You will still need a route within your internal routing tables for this subnet pointing to the internal interface of the pix. The advantage over 1) is that you can keep your routing tables more consistent eg. say you have a spare class C 139.55.57.0/24. You can setup translations as such

static (pVLAN,inside) 139.55.57.1 192.168.50.x (x being one of the pVLAN servers)

static (pVLAN,inside) 139.55.57.2 192.168.50.x

etc etc....

2 is preferable but you do need a spare subnet ( doesn't need to be a whole class c ) and you still need to ensure there is a route internally for this subnet pointing to the Pix internal interface.

HTH.

187
Views
0
Helpful
1
Replies
CreatePlease to create content