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:
description Internet via MPLS
ip address 10.0.10.2 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 10.49.23.215
description LAN FFM branch
ip address 10.49.70.10 255.255.255.0
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
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
ip address X.X.X.80 255.255.255.224
ip nat outside
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?