routing through static NAT configuration on subnets

[Brian Taylor]

When on the subnet (10.0.4.*) pinging devices beyond the subnet works, but pinging via the internal subnet (192.168.2.*) fails. A previous post (here) and subsequent testing determined that the 10.0.4.* network was correctly configured and you experts were no doubt correct that the problem was due to the GATEWAY not being configured correctly at the “other end” (beyond the 10.0.4.*) network.

Now from the description supplied by the other network implementer, the “other end” has statements possibly like:

ip nat inside source static tcp 172.16.10.14 8000 10.0.4.17 8000

Given this scenario, is it possible (e.g. via NAT statements) to actually get normal routing working from the internal subnet, i.e. where I can ping 10.0.4.* from 192.168.2.* (and "telnet 10.0.4.17 8000")? Or perhaps anything we try still won’t work if the gateway is not correctly configured (at both ends)?

Alternatively I have told the other network implementer to set up a normal subnet interface and control access via ACLs. Is this better that static routes? e.g. using: 

interface GigabitEthernet0/1.4
 encapsulation dot1Q 4
 ip address 192.168.0.251 255.255.255.0
 ip access-group GIG140 in
 ip nat inside
 ip virtual-reassembly in
 zone-member security in-zone

[paul driver]

Hello
Your OP is quite hard to understand, Can you elaborate a little?
You mention 10.0.4* which i assume is your wan facing subnet and then host 172.16.10.14 - Do you have subnet for this host within your LAN.

Maybe post a topology diagram or even the running configuration of the router.

[Brian Taylor]

Note I'm only talking about connecting to local area network from 2 closely associated groups.

Network diagram attached.

Local subnet: 192.168.2.* on 2901 router GW 192.168.2.1
New subnet 10.0.4.* on same router GW 10.0.4.2
(Core switch (cisco 3750 stack) 192.168.2.2)
(T1B1 switch (cisco 300) 192.168.2.14 (config: spc-t1b1-idf-sw1-p.txt))
T1B1 switch – on 10.0.4.* subnet to another local area network of unknown configuration possible subnet 172.16.*.* but NAT'd (PAT) from their side to 10.0.4.* for a limited number of IP addresses.

Subnets definitions are:

interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.2.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 zone-member security in-zone
end

interface GigabitEthernet0/1.140
 encapsulation dot1Q 140
 ip address 10.0.4.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 zone-member security in-zone

[MHM Cisco World]

different subnet config in same router with NAT 
config LO with enable NAT no IP inside/outside NAT
this can NATing traffic IN and OUT the traffic.

your topology is perfect but 
can you mention source and destination of packet that you face issue with it ??

[Brian Taylor]

---

@MHM Cisco World wrote:

can you mention source and destination of packet that you face issue with it ??

---

See below: source 192.168.2.*, destination 10.0.4.17 port 8000 (works on 10.0.4.* subnet but not on 192.168.2.* subnet)

[paul driver]

Hello

@Brian Taylor 
T1B1 switch – on 10.0.4.* subnet to another local area network of unknown configuration possible subnet 172.16.*.* but NAT'd (PAT) from their side to 10.0.4.* for a limited number of IP addresses.

---

As this host(subnet) is not subject to NAT but it seems to suggest is reachable as its on the outside of your network then you shouldn't have to do anything......Unless you which to nat that outside  host172.16.10.14 to the inside host 10.0.4.17 on tcp port 8000?

Then the nat statement would read -
ip nat outside source static tcp 172.16.10.14 8000 10.0.4.17 8000

[Brian Taylor]

---

@paul driver wrote:

Unless you which to nat that outside to the inside host 10.0.4.17 on tcp port 8000?

---

I think you are right but I haven't explained the problem well - see my post below. I need to get to 10.0.4.17 on port 8000 (works from this subnet) from the local network 192.168.2.* (can't get to it from this subnet). What "ip nat outside" command can I use to map 10.0.4.17 port 8000 so it is accessible to the 192.168.2.* network?

[Brian Taylor]

Looks like I’ve done a terrible job of explaining the problem.

• When on subnet 10.0.4.* I can get to the other side, “ping 10.0.4.1” and “telnet 10.0.4.17 8000”
• From 192.168.2.* I cannot ping or telnet because the other network has no gateway configured and the packets cannot find a route back.
• Is there any way of using NAT to map 10.0.4.17 port 8000 so that I can telnet to it on the 192.168.2.* network? (i.e. “ip nat outside …”)

The current definition for bridge subnet is:

interface GigabitEthernet0/1.140
 description SPC RES VLAN$FW_INSIDE$
 encapsulation dot1Q 140
 ip address 10.0.4.2 255.255.255.0
 zone-member security in-zone
end

[paul driver]

Hello

If 10.0.4.2 is the outside facing subnet then append NAT to that subnet

int gig0/1.140

ip nat outside
exit

ip nat inside source static tcp192.168.2.*  8000 10.0.4.17 8000

[Brian Taylor]

interface GigabitEthernet0/1.140
 description SPC RES VLAN$FW_INSIDE$
 encapsulation dot1Q 140
 ip address 10.0.4.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
 zone-member security in-zone
end
ip nat inside source static tcp 192.168.2.117 8000 10.0.4.17 8000

I did try this as you suggested but "telnet 192.168.2.117 8000" does not work. It also stops "telnet 10.0.4.17 8000" from working on the 10.0.4.* subnet. I guess I'll have to do some debugging.

[Jon Marshall]

I am so confused trying to work out what you are doing here.

Could you draw a proper topology ie. a logical diagram (can be hand drawn) so we can work out what it is you are attempting to do. 

It seems like you are saying that a 172.16.10.x IP address has been translated to a 10.0.4.x IP and that works if you connect from a 10.0.4.x IP but if you try and connect from a 192.168.2.x IP it doesn't because of the gateway at the remote end (the 172.16.10.x side ?). 

Is that correct ? 

A diagram of just the L3 part ie. the router and interfaces and subnets involved would help. 

Jon

[Brian Taylor]

---

It seems like you are saying that a 172.16.10.x IP address has been translated to a 10.0.4.x IP and that works if you connect from a 10.0.4.x IP but if you try and connect from a 192.168.2.x IP it doesn't because of the gateway at the remote end (the 172.16.10.x side ?). 

Correct Jon - at the remote end the gateway is not configured so bridged traffic configured with "ip nat inside" and a packet source address of 192.168.2.* cannot find it's way back as the device replying to the packet via the unknown router does not have the gateway configured correctly (for example there may be another 192.168.2.* subnet on that network).

See attached diagram and COM router configuration.

[Jon Marshall · Accepted solution]

So the easiest thing to do if you don't mind all your 192.168.2.x traffic being translated whenever it goes to 10.0.4.x then you could do - 

access-list 101 permit ip 192.168.2.0 0.0.0.255 10.0.4.0 0.0.0.255    -   (you can use named acl if you want) 

ip nat inside source list 101 interface gi0/1.140 overload

so the remote site knows how to reach 10.0.4.x and would be able to send the return traffic. 

Jon

[Brian Taylor]

Well brilliant Jon, that worked!! and I can limit the access list:

access-list 101 permit ip 192.168.2.176 0.0.0.0 10.0.4.0 0.0.0.255
ip nat inside source list 101 interface gi0/1.140 overload

How does it work? Does it translate 192.168.2.176 to a 10.0.4.? ip address so the other end can reply?

I guess all traffic must be translated to get it to work.

Does the router have to work harder to do this (we are talking video traffic here)?

Why do you think the 1:1 NAT translation work?

ip nat inside source static tcp 192.168.2.117 8000 10.0.4.17 8000

Brian

[Jon Marshall]

It works by translating any 192.168.2.x IP you allow in the acl to the gi0/1.140 interface IP (10.0.4.2) and the remote side knows how to get to that IP. 

It should not have an effect on the video traffic as it should be minimal overhead although bear in mind NAT can sometimes mess with voice/video traffic so you would have to test but the router overhead will not be an issue. 

So that last translation I assume means the 10.0.4.x subnet can connect to 10.0.4.17 on port 8000 and it is translated to 192.168.2.117 ? 

Jon