×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Accessing server on other network throught NAToutside

Unanswered Question
Dec 15th, 2006
User Badges:

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
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Mon, 12/18/2006 - 01:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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.





Actions

This Discussion