I have a router (R1) that does VTI to a remote site, and that remote devices need to go through the tunnel to reach another device behind a router (R2). The 2nd router R2 I do not have access to, so I am unable to add a static route to find the remote device via R1.
So my thought was to NAT the remote device on R1 from its remote IP of 10.172.40.1 to 10.1.1.45, then R2 could communicate because it is on the same subnet as R1.
interface FastEthernet4 ip address 10.1.1.40 255.255.255.0 ip nat outside ! interface Tunnel1 ip address 10.63.5.2 255.255.255.248 ip nat inside tunnel source 10.1.1.40 tunnel destination 50.xx.xx.xx ! ip nat inside source list NAT interface FastEthernet4 overload ip nat inside source static 10.172.40.1 (remote device) 10.1.1.45 ! ip access-list standard NAT permit 10.172.40.0 0.0.0.255 ! ip route 10.190.0.0 (remote subnet I need to reach) 255.255.255.0 10.1.1.50
In my head driving home it seemed simple enough, but in reality that has not worked. I ping another device with icmp debug on and can see the 'src' is still 10.172.40.1 and not 10.1.1.45. Since I am unable to add a static route on R2, I can not see any other way of the remote subnet communicating back unless it is on the 10.1.1.0/24 subnet.
Any ideas what I am missing or have done wrong?
Hi Francesco, thank you for replying. It is the device at 10.172.40.1 at R1 that needs to communicate with 10.90.0.50 behind R3 which is the router I have no access to. If I did, I would simply add a static route to 10.172.40.0 via 10.1.1.40 (R2).
In the diagram, the PC behind the FW1 is able to communicate to 10.90.0.50 because FW1 has a route to R3 and it NAT's internally to 10.1.1.112 (The PC is at 192.168.2.1). R3 is a Jasper managed router, and I have requested whether a static route could be added but have yet to hear back. If they can not do this, my remaining options are not good short of figuring out how to send to 10.90.0.50 with a source of 10.1.1.45
BTW 10.90.0.50 can ping any device on 10.1.1.0/24 subnet, but nothing else. It is my understanding (or assumption) R3 is doing VTI with dynamic routing but only advertising the one subnet, so devices on 10.90.0.0 only could ever pass traffic to 10.1.1.0.
I am not really clear on how R1 and R2 are connected, as the partial configuration you posted shows a simple GRE tunnel and no VTI configuration. I assume this is from R2 ? I understand you control R1 and R2, but not R3 ? Can you post the full configs of R1 and R2 ?
Below are the configs as of this morning. R1 is a test/development unit whereas R2 is presently in use for a different purpose, but was available for this testing.
Originally R1 was using EIGRP with 2x R2 routers (could call them R2A and R2B), but for this issue I changed that to only use just the one R2 router as I wanted to keep things simple as I could.
crypto isakmp policy 1
|crypto isakmp policy 1
crypto isakmp policy 2
crypto isakmp key ******* address 50.xx.xx.xx
crypto ipsec transform-set TM1 esp-aes 256 esp-sha-hmac
crypto ipsec transform-set T1 esp-aes esp-sha-hmac
crypto ipsec profile IPSEC
set transform-set T1
crypto map VZ1 11 ipsec-isakmp
set peer 50.xx.xx.xx
set transform-set TM1
match address 151
ip address 10.63.5.2 255.255.255.248
ip nat inside
ip virtual-reassembly in
tunnel source 10.1.1.40
tunnel destination 50.xx.xx.xx
ip address 10.1.1.40 255.255.255.0
ip nat outside
ip virtual-reassembly in
crypto map VZ1
encapsulation dot1Q 100
ip address 38.xx.xx.xx 255.255.255.0
router eigrp 1
network 10.1.1.0 0.0.0.255
network 10.63.5.0 0.0.0.7
network 10.80.0.0 0.0.0.255
network 38.xx.xx.0 0.0.0.255
redistribute connected route-map STATIC
redistribute static route-map STATIC
neighbor 10.63.5.1 Tunnel1
eigrp router-id 10.1.1.40
no eigrp log-neighbor-changes
ip nat inside source list NAT interface FastEthernet4 overload
ip nat inside source static 10.172.40.1 10.1.1.45
ip route 0.0.0.0 0.0.0.0 10.1.1.20
ip route 10.55.7.0 255.255.255.0 10.1.1.35
ip route 10.190.0.0 255.255.255.0 10.1.1.50
ip access-list standard NAT
permit 10.172.40.0 0.0.0.255
route-map STATIC permit 10
match ip address 20
set metric 56 100 255 1 1500
access-list 20 permit 10.172.40.0 0.0.0.31
access-list 20 permit 10.80.0.0 0.0.0.255
access-list 20 permit 10.55.7.0 0.0.0.255
access-list 100 permit ip 10.172.40.0 0.0.0.255 any
access-list 151 permit gre host 10.1.1.40 host 50.xx.xx.xx
I have done some testing, and I don't think you can get around at least a default static route on the Jasper router. The problem with NAT is that if you try that on R1, there is no outside network on R1 that you can transate to. 10.1.1.0/24 is on R2, so the translation won't work. I tried policy routing on R2 sending everything coming from 10.190.0.0/24 to 10.172.40.0/24 through the VTI tunnel, but since the Jasper router doesn't have a route, the traffic won't even make it to R2.
That said, it is hard to imagine that R3 doesn't actually have a default route. Assuming that route is there, try and apply the policy map below to the interface connecting R2 and R3:
access-list 101 permit ip 10.190.0.0 0.0.0.255 10.172.40.0 0.0.0.255
match ip address 101
set interface Tunnel 0
description Link to R3
ip policy route-map R3_TO_R1
Thanks for replying. I think at this point my issue is with R1 to R2 that I will need to look further into. I am able to ping from a device at 10.190.0.0 to the R1 router, but R1 to the device fails. Doing a traceroute I do see the first hop is the other end of the tunnel, but everything after that is * * *. I had initially thought that R3 was suppose to be able to only communicate with the 10.1.1.0 subnet of R2, that is not the case.
R3 is using our edge router as it's gateway, and applying a static route for 10.172.40.0 to R2 solves the remote devices being able to reach R1. As R1 contains a lot of unnecessary configuration I am going to start from scratch on Monday to include only that which is needed. Suffice to say this is not an issue or need to use NAT.
if you can reach R1 from the 10.190.0.0/24 network that means there has to be at the very least a default route installed on R3.
Try and configure the below route map, and apply it to the tunnel interface on R2:
access-list 101 permit ip 10.172.40.0 0.0.0.255 10.190.0.0 0.0.0.255
match ip address 101
set ip next-hop 10.1.1.50
ip policy route-map TUNNEL-PBR