Were you able to confirm that

support systemsGo · ‎04-25-2017

Hello.

We have an interesting issue on setting up NAT on GRE tunnels.

In the setup, there are 3 routers in three different sites.

Router in Site A, Site B, and Site C.
We do not have access to any of the equipment in Site C. (ie. The configuration cannot be changed in Site C)

We have client PCs on 192.168.1.0 and 192.168.2.0 subnets sitting behind router in Site A.

In Site B, the router there has two tunnels, one connecting to Site A (Tunnel2), and the other to Site C (Tunnel1).
We cannot change the location of where these tunnels are configured.

The issue is that PCs in the subnet 192.168.2.0 in Site A need to talk to servers in the subnet 10.1.1.0 in Site C.
This is already working for PCs in Site A on the 192.168.1.0 subnet.
However, there already exists a 192.168.2.0 subnet in Site C.

We need some way for clients in subnet 192.168.2.0 in Site A to look like they are coming from the 192.168.1.0 subnet in order to be able
to reach the servers in Site C.

What we have tried to do is put a NAT on the tunnel interfaces on the Router in Site B.

Router B:

interface Tunnel1
description (Connection to Site C)
ip address 10.0.1.230 255.255.255.252
ip mtu 1000
ip flow ingress
ip nat outside
ip virtual-reassembly
ip tcp adjust-mss 950
tunnel source GigabitEthernet0/1
tunnel destination 85.94.121.4
tunnel protection ipsec profile ipsec_encryption shared

interface Tunnel2
description (Connection to Site A)
ip address 10.45.255.61 255.255.255.252
ip mtu 1000
ip flow ingress
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 950
tunnel source GigabitEthernet0/1
tunnel destination 121.43.55.181
tunnel protection ipsec profile ipsec_encryption shared

ip access-list extended NAT-TRANSLATION
permit ip 192.168.2.0 0.0.0.255 host 10.1.1.10

ip nat inside source route-map GRE-NAT pool NAT-1

route-map GRE-NAT permit 10
match ip address NAT-TRANSLATION

ip nat pool NAT-1 192.168.1.45 192.168.1.47 prefix-length 24

(We made sure there were no PCs that are using the ip addresses in the NAT pool. Global IP addresses shown are not the real ones.)

We can see the translation happening on Router B, but are unable to connect from the PC in the 192.168.2.0 subnet in Site A (ping and traceroute both fail).

Pro Inside global Inside local Outside local Outside global
icmp 192.168.2.45:1 192.168.1.45:1 10.1.1.10:1 10.1.1.10:1

Ping and traceroute to the server in Site C (10.1.1.10) still works from PCs in the 192.168.1.0 subnet in Site A.

Is there something we're missing? Are we doing the translation on the right router? Or is this even possible?

Jon Marshall · ‎04-26-2017

So the site A router does not have a tunnel to the site C router ?

Assuming that is the case this is perfectly possible and your configuration looks fine although I would not bother with the route map part.

But your translations are wrong because the inside global address should be 192.168.1.45 and the inside local address 192.168.2.45 so something is wrong either in the configuration you posted, the description of the problem or perhaps a bug.

Jon

support systemsGo · ‎04-26-2017

Site A router does not have a tunnel to site C.

We tried it without doing the route-map and it also gives the same result (although now the translations stay longer)

And you are right.

It is actually,

Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.45:1 192.168.2.45:1 10.1.1.10:1 10.1.1.10:1

It was my mistake. I mistyped in the original post.

I can see the translation as above, but the 192.168.2.45 pc cannot reach the 10.1.1.10 network.

Ping fails.

A traceroute from 192.168.2.45 PC in site A shows that it stops at the Tunnel 2 interface at Site B Router.

1 1ms <1ms <1ms 192.168.2.1

2 <1ms <1ms <1ms 192.168.5.137

3 25ms 25ms 25ms 10.45.255.61

4 * * * Requested timed out.

5 * * * Requested timed out.

6 * * * Requested timed out.

7 * * * Requested timed out.

8 * * * Requested timed out.

I forgot that also on Tunnel 1 on Site B routerthere is this statement:

ip summary-address eigrp 123 192.168.1.0 255.255.255.0 250

And in the other part of the configuration on the router in Site B, there are these statements:

router eigrp 123

distribute-list 1 out Tunnel1

access-list 1 permit 192.168.1.0 0.0.0.255

Can you see anything which would cause this break in the path?

PCs on the 192.168.1.0 subnet can route to the next hop after that, which is 10.0.1.229 at Site C router.

Jon Marshall · ‎04-26-2017

Not sure why you are using a distribute list and a summary address to site C at the same time ?

As suggested does site B just have a route for 192.168.2.0/24 pointing to site A or does it also receive a route for that subnet from site C. ?

I don't think it is GRE as I did a quick lab with GRE and NAT and it worked fine.

Jon

support systemsGo · ‎04-26-2017

They are there to limit the routes being advertised to site C.

(Was not configured by us.)

Site B receives the route for 192.168.2.0/24 from site A via EIGRP.

It does not receive a route for that subnet from site C.

Also, when we do an debug ip nat detailed, as soon as we put ip nat outside on tunnel 1, we see this:

Apr 27 02:04:16: NAT*: GRE port: 0 - [63155]
Apr 27 02:04:17: NAT*: GRE port: 0 - [64059]
Apr 27 02:04:18: NAT*: GRE port: 0 - [64875]
Apr 27 02:04:19: NAT*: GRE port: 0 - [379]
Apr 27 02:04:20: NAT*: GRE port: 0 - [1256]
Apr 27 02:04:21: NAT*: GRE port: 0 - [2468]
Apr 27 02:04:22: NAT*: GRE port: 0 - [3719]
Apr 27 02:04:23: NAT*: GRE port: 0 - [4974]
Apr 27 02:04:24: NAT*: GRE port: 0 - [23220]
Apr 27 02:04:25: NAT*: GRE port: 0 - [2005]
Apr 27 02:04:26: NAT*: GRE port: 0 - [9987]
Apr 27 02:04:27: NAT*: GRE port: 0 - [11130]
Apr 27 02:04:28: NAT*: GRE port: 0 - [12559]
Apr 27 02:04:29: NAT*: GRE port: 0 - [13912]
Apr 27 02:04:30: NAT*: GRE port: 0 - [15569]
Apr 27 02:04:31: NAT*: GRE port: 0 - [17276]
Apr 27 02:04:32: NAT*: GRE port: 0 - [19074]
Apr 27 02:04:33: NAT*: GRE port: 0 - [20417]
Apr 27 02:04:34: NAT*: GRE port: 0 - [20951]
Apr 27 02:04:35: NAT*: GRE port: 0 - [22341]
Apr 27 02:04:36: NAT*: GRE port: 0 - [23735]
Apr 27 02:04:37: NAT*: GRE port: 0 - [24200]
Apr 27 02:04:38: NAT*: GRE port: 0 - [27502]

Even when we put ip nat inside on Tunnel 2, there is no change in the debug of the ip nat when we try to ping/traceroute from 192.168.2.45 to 10.1.1.10. Usually you would see some other traffic in the debug if the nat was working correctly.

cofee · ‎04-26-2017

I dropped the configuration you shared in GNS3 and I encountered some issues, reproduced debug results that you posted. Below is the debug output when I simply pinged 10.1.1.10 from router A and not sourcing from 192.168.2.0 behind router A.

RouterB#

*Apr 26 21:51:06.095: NAT*: GRE port: 0 - [6]

Apr 26 21:51:04.115: NAT*: GRE port: 0 - [5]

I just had to make sure that all routing was properly configured.

Router A –

ping 10.1.1.10 source 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:

Packet sent with a source address of 192.168.2.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/46/84 ms

Router B – Pro Inside global Inside local Outside local Outside global

icmp 192.168.1.45:17 192.168.2.1:17 10.1.1.10:17 10.1.1.10:17

*Apr 26 22:38:23.499: NAT*: s=192.168.2.1->192.168.1.45, d=10.1.1.10 [81]

Router C –

debug ip packet 100

IP packet debugging is on for access list 100

Extended IP access list 100
9 permit ip host 192.168.1.45 host 10.1.1.10 (75 matches)

*Apr 26 22:39:03.259: IP: s=192.168.1.45, d=10.1.1.10, pak 685D3DA0 consumed in input feature , packet consumed, MCI Check(80), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Apr 26 22:39:03.355: IP: s=192.168.1.45, d=10.1.1.10, pak 685D3428 consumed in input feature , packet consumed, MCI Check(80),

I would suggest to check all network blocks involved in this test are pointing in right direction and reachable using “ show ip cef x.x.x.x”
I would also suggest to remove ip nat inside and ip nat outside and then reapply it to the tunnel interface. Sometimes there are software glitches and can be fixed by doing such things.

support systemsGo · ‎04-26-2017

All network blocks are reachable, (Cannot test from site C though) and I tried removing and adding the NAT back, but still not seeing the translation happen as it should be.

Tried ping from the source and also from PC in 192.168.2.45, but it is still the same.

cofee · ‎04-27-2017

Even though you can't test at site C, but you mentioned in your original post that network 192.168.1.0/24 at site A can reach 10.1.1.0/24 at site C, so that means site C has reachability to 192.168.1.0/24 and this is block you are using to NAT 192.168.2.0/24 so that shouldn't be a problem.

cofee · ‎04-27-2017

How about using site A router for NATing instead of B? you can try that.

cofee · ‎04-26-2017

Were you able to confirm that natted traffic is actually reaching site c? Also how does router at site b differentiate which way to go when destination network is 192.168.2.0/24 since you mentioned it exists at site a and c ? Since router at site b connects a and c could there be a route confusion when routing traffic to network 192.168.2.0/24?

Paul Smith · ‎04-27-2017

ip mtu 1000? Any reason why this setting is so low?

GRE Tunnel NAT Issue