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:
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
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?
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...