1

I have a Cisco router with a tunnel configured:

# sh ip int brief
FastEthernet0/1 192.168.1.1
Dialer1         1.2.3.4
Tunnel1         169.254.1.10

Dialer1 is a pppoe internet connection and Tunnel1 a VPN connection to another network - 172.16.1.0/24. Routes are configured for 192.168.1 and 172.16.1. Network is working as expected between these 2 networks, and between 192.168 and the internet (ip nat outside on dialer1, inside on fa0/1, and ip nat inside source list 192-168-1-0 dialer1 overload)

However, I am unable to connect to 172.16.1 network from the router itself - the source address comes from the tunnel interface IP of 169.254.x.y. I could add a route for 169.254 on the remote network, but would rather want packets originating from the router to have the source address translated to 192.168.1.1. Is it possible to do this?

2

NAT translates addresses from an inside interface to an outside interface. So packets coming from the router won't be translated.

Since the other network already has an interface on 169.254.x.y, I don't think adding a route will help.

| improve this answer | |
  • I'm not as familiar with Cisco's implementation of translation as that of linux. In a linux environment I would be able to do it - surely I could use a nat rule on a Cisco to do something similar to this - iptables -t nat -A POSTROUTING -o eth0 -d 172.16.1.0/24 -j SNAT --to-source 192.168.1.1 – Brett Sep 25 '15 at 12:53
  • Sadly, no. That's not a feature Cisco has implemented, presumably because there is no need. You could try sourcing your traffic from the inside interface. I've never tried it, but it might work. However, I suspect your problem is not caused by routing. – Ron Trunk Sep 25 '15 at 12:58
2

Finally got it to work, after much playing around. The high level steps to complete were as follows:

  1. Create a general NAT access list for inside traffic to internet and remote network (with permit and deny rules)
  2. Create a specific NAT access list to match router-originated traffic
  3. Add outside matcher to tunnel interface
  4. Create 2 nat rules, 1 for each access list in #1 and #2 above.

Here's the config:

ip access-list extended INSIDE_TO_OUTSIDE_GENERAL
 deny ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255 ! Match local private to remote private traffic - deny translation
 permit ip 192.168.1.0 0.0.0.255 any ! translate all other local traffic
ip access-list extended FROM_ROUTER_DOWN_TUNNEL
 permit ip host 169.254.1.10 172.16.1.0 0.0.0.255 ! allow traffic with source address matching tunnel interface and a destination of remote private

ip nat inside source list INSIDE_TO_OUTSIDE_GENERAL interface Dialer1 overload ! attach inside to outside traffic - excludes pvt to pvt
ip nat inside source list FROM_ROUTER_DOWN_TUNNEL interface FastEthernet0/1 overload ! traffic from local tunnel interface to remote private gets translated to FA0/1 (i.e. inside private) IP.
int Tunnel1
  ip nat outside

The adjustment to the first access-list (the addition of the deny) allows me to add the ip nat outside to the tunnel and not translate 192.168 traffic headed to 172.16. The 2nd access-list allows me to identify router-originated traffic headed to remote private network, and the 2nd ip nat inside rule ensures translation from tunnel IP to private inside IP (.1.1).

Working like a charm.

| improve this answer | |
1

As @RonTrunk pointed out, NAT translates from an inside interface to an outside interface. The router can source lots of thing from interfaces with the correct commands. You could create an access list of the addresses to translate, add a loopback as a inside interface in the access list, and try to source what you want translated from that.

For example, some source commands:

ip tftp source-interface Loopback0
ip ftp source-interface Loopback0
ip ssh source-interface Loopback0
ip tacacs source-interface Loopback0
ip domain lookup source-interface Loopback0
logging source-interface Loopback0
snmp-server trap-source Loopback0
ntp source Loopback0
| improve this answer | |
  • That sounds like something that might work, been trying to configure this for a few hours now and have not been able to come right. To clarify, there is no nat on the tunnel interface - traffic going to 172.16.1 comes from 192.168.1 and routes without translation. So I would basically need an ip nat inside source list X interface Loopback with the loopback interface having a 192.168.1 ip (which is routable to the 172.16.1 network) ? – Brett Sep 25 '15 at 15:21
  • Now I am confused. Are you trying to NAT traffic from the tunnel to the dialer interface? Your question is about NAT from traffic originating on the router, not the tunnel. You can make the tunnel an inside interface if you wish to NAT from it to the dialer. – Ron Maupin Sep 25 '15 at 15:24
  • I want traffic from the router heading down the vpn to the remote network to come from the ip on fa0/1. On the router, I have ip route 172.16.1.0 255.255.255.0 Tunnel1. When I ping 172.16.1.10 (a host on the remote network) from the router, I see source address of 169.254.1.10 on the ICMP packets (on the .10 host). 169.254 is unroutable on the 172.16.1 network. I want traffic originating from the router with a destination of 172.16.1.0/24 to have a source address of 192.168.1.1 – Brett Sep 28 '15 at 7:46
  • That's why I was thinking that policy routing might work. If i have an access list that matches traffic from the router to the 172.16.1 network, then somehow route it through a loopback interface that has a 192.168.1 IP on and has NAT configuration to translate it..... – Brett Sep 28 '15 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.