Help me NAT from WAN to LAN without the LAN has gateway configured?

[Joris Syen]

Dear,

We are replacing an old software router where we need to try extract to same configuration of to a 2901 router.

I basically was able to configure it similarely, except this issue:

There is a routing between WAN and LAN (Office and Production), where could ping from the WAN to a LAN ip, receiving a response from the LAN ip (so not from the NAT translated address). This without the LAN device had a gateway configured. I am not able to get this to work in any way: if the LAN device has no gateway, I get no respons.

WAN

IP 143.25.128.31

SN 255.255.0.0

GW 143.25.128.30

LAN

IP 172.16.1.129

SN 255.255.0.0

NO GW

Ping using the software router was possible from 143.25.128.31 to 172.16.1.129 and it even "received" the message from "172.16.1.129" and not from "143.25.128.30". I am not able to get this to work in either way. This is what I basically came up with until now (clean start):

Router>enable
Router#conf t

Router(config)#hostname URLRTR000X019A
URLRTR000X019A(config)#no ip domain-lookup

URLRTR000X019A(config)#interface Gi0/1
URLRTR000X019A(config-if)#ip address 143.28.175.30 255.255.0.0
URLRTR000X019A(config-if)#no shutdown
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#interface Gi0/0
URLRTR000X019A(config-if)#ip address 172.16.0.19 255.255.0.0
URLRTR000X019A(config-if)#no shutdown
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#ip route 0.0.0.0 0.0.0.0 143.28.175.1

--at this moment, all traffic is routed between the gateways
--unknown destinations are routed to 143.28.175.1 (external gateway)

URLRTR000X019A(config)#interface gi0/0
URLRTR000X019A(config-if)#ip nat inside
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#interface gi0/1
URLRTR000X019A(config-if)#ip nat outside
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#ip access-list standard NAT_THESE_ADDRESSES
URLRTR000X019A(config-std-nacl)#permit 172.16.1.129 0.0.0.0
URLRTR000X019A(config-std-nacl)#exit
URLRTR000X019A(config)#ip nat inside source list NAT_THESE_ADDRESSES interface Gi0/1 overload

I also tried

-- or

URLRTR000X019A(config)#ip access-list standard NAT_THESE_ADDRESSES
URLRTR000X019A(config-std-nacl)#permit 143.28.175.31 0.0.0.0
URLRTR000X019A(config-std-nacl)#exit
URLRTR000X019A(config)#ip nat outside source list NAT_THESE_ADDRESSES interface Gi0/1 overload

-- or

URLRTR000X019A(config)#ip access-list standard NAT_THESE_ADDRESSES
URLRTR000X019A(config-std-nacl)#permit 143.28.175.31 0.0.0.0
URLRTR000X019A(config-std-nacl)#exit
URLRTR000X019A(config)#ip nat outside source list NAT_THESE_ADDRESSES interface Gi0/0 overload

It does not do the job, no replies at all. Can anyone help me on this please?

Best Regards,

Joris

[Jon Marshall]

Joris

Couple of clarifications needed -

1) the client has no default gateway so are you relying on proxy arp ?

What I mean by that is that with your old setup you weren't doing any NAT translations on the WAN IPs were you ?

2) Is it just ping you need to be able to go to the real IP and if so can the ping be initiated from both sides or is it just from the WAN side you want it ?

Jon

[Joris Syen]

Hello Jon,

Basically we have 2 networks, Production and Office.

Most of the time, we need a NAT for the connection from Production to Office.

This is because the routers in the Office network do not have the Production network in the routing table. We cannot control that.

So that is why I configured the Production interface as inside and the Office interface as outside.

Now for a few connections, a station needs to connect from Office to Production, to a Production device that is not capable of defining a default gateway (it is a PLC Controller). Plus (probably): The Office device runs software that requires the "answers" are coming from the IP adres of the device. From these few devices, it is not required that I can ping to the Office network (would be impossible since no gateway). They only need to reply from messages that come from Office using NAT. These Office deivces are in the same network as the Office interface, they have the .30 gateway specified (our router) and basically it is just 1 device in Office connecting to 5 devices in Production.

I found out that if I configure the Office as inside and the Production as outside, I can get this to work. But this way I believe my other NAT in the other direction will stop working. So I really need it to be Office outside, Production inside.

P.S. this is what worked (but is not applicable):

URLRTR000X019A(config)#interface gi0/0
URLRTR000X019A(config-if)#ip nat outside
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#interface gi0/1
URLRTR000X019A(config-if)#ip nat inside
URLRTR000X019A(config-if)#exit

URLRTR000X019A(config)#ip access-list standard NAT_THESE_ADDRESSES
URLRTR000X019A(config-std-nacl)#permit 143.28.175.31 0.0.0.0
URLRTR000X019A(config-std-nacl)#exit
URLRTR000X019A(config)#ip nat inside source list NAT_THESE_ADDRESSES interface Gi0/0 overload

[Jon Marshall]

Joris

You say a PLC could not ping the office network because it has no default gateway so how does it reply to ping ie. the source IP will be an office IP and the PLC has no default gateway.

This is what I was asking in my first question ie. when you ping a PLC from an office device are you translating the office IP to an IP on the PLC subnet ?

If not then how does the PLC know where to send the return traffic ?

Jon

[Joris Syen]

Jon,

The PLC cannot ping the Office network because it has not DG. That is correct. But when it receives a ping from a device in the Production network (the router Production interface) it CAN reply to that.

The Office network should ping to production using the gateway (= the router), then the router should translate that to a production IP and sent it to the PLC. The plc should then respond to the router (source IP) and the router should send the response to the Office device using the PLC ip address as source.

This works perfectly when I specify the Production network as "outside" as specified above, but I could not get it to work with Production being "inside".

[Jon Marshall]

Joris

Okay I understand now.

Is there just one device in the office network that needs access to the PLC devices ?

If so do you have a spare IP in the production PLC network ?

Basically you need to do two things as far as I can see -

1) you need to translate the office device to a production IP but it probably can't be the router's own interface IP in the production network

and

2) you need to make sure when the PLC responds it's source IP is not translated.

Have I understood correctly and if so can you answer the above questions.

Jon

[Joris Syen]

Hello Jon,

"1) you need to translate the office device to a production IP but it probably can't be the router's own interface IP in the production network"

I don't see why it can't be the routers own interface IP. Is that technically impossible?

"2) you need to make sure when the PLC responds it's source IP is not translated."

Preferably it is not translated when responding. I am not sure it is a requirement.

I believe all of this should be exaclty the same as my computer accessing the internet.

When I ping 8.8.8.8 I get reply from 8.8.8.8 although 8.8.8.8 thinks it is replying to my public IP.

So all I need is a NAT from inside to outside but also for some specific devices (using the same interfaces and interface IPs) a NAT from outside to inside. Seems impossible to do thus far.

[Jon Marshall]

Joris

1) the problem is that from outside to inside you cannot do a NAT overload which is why when you flipped the NAT statements around it worked for you.

It's a bit complicated but basically with NAT from inside to outside routing is done before NAT.

So if the office IP is translated to the router's IP then when the PLC sends the return traffic the router does a route lookup on that IP and sees it is for it's own IP address so does not forward the traffic.

There is a way around this where you add a host specific route for the translated IP so it does the forward the packet but you can't do this with the router's own interface IP because on newer IOSs the router installs a host route for it's own interface IP.

But you could do it with a spare IP from the production IP subnet.

Like I say it's a bit complicated to describe but you need to do a static translation for the office device that contacts the PLCs.

Assuming it is one device on the office network ?

2) I thought it was a requirement and in fact that was what the whole thread was about ?

Jon

[Joris Syen]

Hello Jon,

Thank you for your anwers.

You say I cannot do NAT overload when doing outside to inside NAT.

I have a spare production IP addresses no problem, for example the 172.16.0.18

Can you help me with the commands required to configure this? Because I have no experience in that matter.

Yes it is one device on the Office network (143) that needs to connect to 5 devices on the production network (172).

Thank you,

Joris

[Jon Marshall · Accepted solution]

Joris

Assuming you want to preserve the IP address of the production clients then as an example -

1) the office device needs to be presented as 172.16.0.18 to the PLCs so on your router -

"ip nat outside source static <real IP of office device> 172.16.0.18 add-route"

note the "add-route" part is important, hopefully you have that option.

2) to preserve the IPs of the PLCs then you will need to use an extended acl for your NAT eg.

access-list 101 deny icmp host <PLC IP> host 172.16.0.18 echo-reply
... you need a line for each PLC IP
access-list 101 permit ip 172.16.0.x <wildcard mask> any

ip nat inside source list 101 interface gi0/1 overload

note also I have used a numbered acl but if you want to use a named acl that will work fine as well.

Let me know how you get on with it.

Jon

[Joris Syen]

Dear Jon,

Thank you very much for sharing your time and experience on this matter. I got stumbled of the amount of great feedback I received from you in this toppic.

Sorry to disappoint you, but it turned out that the PLC programmer was wrong and the PLC's DO have gateway addresses specified. This meant I only needed to link an ACL to the general NAT, to avoid the PLC's addresses being translated when responding to Office devices. It worked fast and well.

I must say I will not use 'Cisco Configuration Professional' to configure this type of routers (2901) from scratch in the future anymore, because it seems the wizards and scripts included are very based on a 'LAN to Internet' configuration.I will use the command line and after initial configuration I will tell the customer to use CCP to do adjustments on ACL's or network object groups.

Thanks again for the feedback.

Joris

[Jon Marshall]

Joris

Just a quick update.

The first part of representing the office device to the PLCs as an internal IP is fine.

What I am not totally sure of is the other part because it depends on the order of NAT translations ie. I am assuming the destination IP is 172.16.0.18 and hasn't already been changed.

I will do a quick lab to test but if the IPs of the PLCs are being translated then change the IP of 172.16.0.18 in the acl to the real office IP and see if that works.

I'll get back to you.

Jon

[Jon Marshall]

Joris

Just did a quick lab and the results were a bit surprising.

If I ping from the PLC to the office device then to preserve the IP of the PLC you need the configuration I posted using an extended acl.

If I ping from the office device to the PLC then you don't seem to need the extended acl ie. it keeps the PLC's real IP even when the acl says NAT everything.

Not what I expected to see and I may do it again just to retest.

But basically you need to do the static translation for the office device and then for the other part just experiment is all I can say at the moment.

Jon