I have a central NOC and several remote offices. All running RB493G. The core network addresses are in the 10.0.0.0/8 network with the second and third octet changing based on physical location. The last octet is reserved for local devices. The NOC router also runs PPTP Server to allow the remote office routers to connect via PPTP. PPTP is using 172.16.0.0/16 network for its transport. All is working as expected with one minor routing issue that I have not been able to overcome.
If I make a connection from a device 10.14.1.100 at Remote Office A to a device 10.43.1.200 at Remote Office B, the device in Office B shows the source address as 172.16.0.1 which is the PPTP address of the NOC router. The packets passed through the NOC to get to Office B but I need the source address to appear as 10.14.1.100 so the return path works properly.
I have added some pertinent info, I thought might be helpful. What additional information can I provide to aide in your suggestions?
No that is how it is shown… Just for curiosity sake, I added an out interface to Ether1 but it did not change anything.
Currently I am just pinging from the 10.14.255.1 to 10.14.1.2
Using “/ip firewall connection print” I can see the ICMP traffic passing through the NOC
9 icmp 172.16.255.2 10.14.1.2 48s
And when it arrives at the 10.14.1.1 router
97 S icmp 172.16.255.2 10.14.1.2 6m40s
It would appear that my issue is at the originating router but this is where I cannot see the forest for the trees…
10.14.255.1 is not shown in your original diagram and I’m not sure that we have seen the NAT table related to that subnet’s router. Likewise, 172.16.255.2 isn’t shown either. Please clarify.
Sorry, 10.14.255.0/24 with PPTP of 172.16.255.1 can be considered Remote Office C and is configured exactly like the other two. I am using it for testing because it is on my test bench and not in production.
If 172.16.255.1 is the remote PPTP address then is 172.16.255.2 the NOC end? If so it looks as if it is the NOC doing the SRC NAT - that rule I pointed to looks wrong…
Sorry for my delay but we did resolve the issues we were having. I had not actually tried OSPF in the past but we sat down a watch a number of videos and walk through whitepapers and felt comfortable enough to unleash it on the network. Initially between two routers and then we added additional routers one at a time until all eight were running OSPF. We would test connectivity after every addition and found that the routes we were having trouble with before, started working fine with the implementation of OSPF.
Thanks to everyone who tried to help. I strongly recommend OSPF if you have more than a single router in your network. It would have saved us several man-days while trying to make the complexities of our network integrations make sense.