×

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.

NAT from tunnel interface

Unanswered Question
Jun 16th, 2014
User Badges:

Hi everyone,

don't know if I'm just stupid or have hit a bug...

I was faced with the request to help out our training department. They will conduct a training in a new facility this week and the ISP did not deliver DSL on time. The training facilities are in one of our branch offices that is connected to headquarters using MPLS from a third party. At headquarters we have Internet avilable in the datacenter thus my idea was to provide a router pair and a tunnel between them facilitating the existing MPLS line.

training - R1 - branch LAN - MPLS cloud - datacenter LAN - R2 - Internet

R1 is simply intended to provide DHCP and one tunnel endpoint, R2 is the other tunnel end point also doing NAT.

Everything went fine - except for the NAT. The strange part in it is, that the access-list used to indicate NAT-egliable traffic doesn't work as intended. The problem is solved but in a way that I didn't like very much thus I created an extra VRF on the routers to be absolutely sure that no traffic can be mingled between training (external people) and company LAN.

The relevant config is the following:

R1

interface Tunnel0
 description Internet via MPLS
 ip address 10.0.10.2 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 10.49.23.215
!
interface FastEthernet0/0
 description LAN FFM branch
 ip address 10.49.70.10 255.255.255.0
!
interface FastEthernet0/1
 description LAN FFM Training
 ip address 192.168.70.1 255.255.255.0
!
ip route 10.0.0.0 255.0.0.0 10.49.70.250
ip 
route 0.0.0.0 0.0.0.0 Tunnel0

 

R2

interface Tunnel0
 description Internet via MPLS
 ip address 10.0.10.1 255.255.255.252
 ip nat inside
 tunnel source FastEthernet0/1
 tunnel destination 10.49.70.10
!
interface FastEthernet0/0
 description Internet
 ip address X.X.X.80 255.255.255.224
 ip nat outside
!
interface FastEthernet0/1
 description LAN LEJ datacenter
 ip address 10.49.23.215 255.255.255.240
!
access-list 1 permit any
ip nat inside source list 1 interface FastEthernet0/0 overload
!
ip route 10.0.0.0 255.0.0.0 10.49.23.220
ip route 0.0.0.0 0.0.0.0 X.X.X.94
ip route 192.168.70.0 255.255.255.0 Tunnel0

 

Keep in mind: this is the working configuration. I normally would have used another access-list on R2. I tried with access-list 1 permit 192.168.70.0 0.0.0.255 log but even when debugging NAT never ever a packet hit this ACL. So I thought, maybe the tunnel IPs shall be used instead (really wild guessing) thus adding access-list 1 permit 10.0.0.0 0.255.255.255 log but that didn't change anything. So I thought let's find out what then would trigger NAT by adding a third line access-list 1 permit any log. Still no single hit. But when replacing the whole access-list with just the line access-list 1 permit any log it works like a charm. This is already very strange as the statement was on the access-list at the end but was never hit - as a single statement it works. This is absolutely different from what I'm used to! Also the intial thought to only allow the training LAN works like a charm when having no tunnel interface involved - I know for sure. Of course I tried 4 different IOS versions from 11.something to 15.1 - all resulting in the same situation.

As said earlier having an all-open-NAT is not what I would like to have in the datacenter I ended creating a VRF on R1 and R2 resulting in a little bit changed config - if someone would be interested I can provide that as well.

My thought is the following: there seems to be a bug in IOS (since long) that has to do with the combination tunnel and NAT. I never found out which source IP the router thinks would trigger the NAT (maybe the tunnel source/destination IP instead of the tunnel IP) but then it should have worked with the whole 10.0.0.0/8 in the access-list.

Anyone ever had the same problem? Anyone that can verify that problem? Any thoughts on the setup/config that could cause this strange behaviour?

BR

Björn

 

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Actions

This Discussion