Need some Routing Help Please

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?

Thank you in advance…
-greg
BasicVPN.jpg
NOC-Routes.jpg
OfficeB-Connections.jpg

What does your NAT table look like in IP Firewall?

Remote Office A:

/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" disabled=no \
    out-interface=ether1-gateway

Remote Office B

/ip firewall nat
add action=dst-nat chain=dstnat comment="VoIP Administration" disabled=no dst-addr
    12.X.Y.Z dst-port=22,80,443,3306,9001,69 protocol=tcp src-address-list=\
    "FULL UNBLOCK" to-addresses=10.14.1.2
add action=dst-nat chain=dstnat comment="Remote VoIP Connectivity" disabled=no \
    dst-address=12.X.Y.Z dst-port=5060-5061 protocol=udp src-address-list=\
    "Remote VoIP Connections" to-addresses=10.14.1.2
add action=dst-nat chain=dstnat comment="Remote VoIP Media UDP" disabled=no \
    dst-address=12.X.Y.Z dst-port=1024-65535 protocol=udp src-address-list=\
    "Remote VoIP Connections" to-addresses=10.14.1.2
add action=dst-nat chain=dstnat comment="IAX from Dallas" disabled=no dst-address=
    12.X.Y.Z dst-port=4569 protocol=udp src-address-list="" to-addresses=\
    10.14.1.2
add action=dst-nat chain=dstnat comment="Carrier VoIP SIP UDP" disabled=no \
    dst-address=12.X.Y.Z dst-port=5060-5061 protocol=udp src-address-list=\
    BroadvoxSIP to-addresses=10.14.1.2
add action=dst-nat chain=dstnat comment="Carrier VoIP Media UDP" disabled=no \
    dst-address=12.X.Y.Z dst-port=1024-65535 protocol=udp src-address-list=\
    BroadvoxMedia to-addresses=10.14.1.2
add action=dst-nat chain=dstnat comment="LPT Access SALES10" disabled=no dst-addre
    12.X.Y.Z dst-port=8810 protocol=tcp src-address-list="FULL UNBLOCK" \
    to-addresses=10.14.1.10 to-ports=80
add action=dst-nat chain=dstnat comment="LPT Access SALES11" disabled=no dst-addre
    12.X.Y.Z dst-port=8811 protocol=tcp src-address-list="FULL UNBLOCK" \
    to-addresses=10.14.1.11 to-ports=80
add action=dst-nat chain=dstnat comment="LPT Access SALES12" disabled=no dst-addre
    12.X.Y.Z dst-port=8812 protocol=tcp src-address-list="FULL UNBLOCK" \
    to-addresses=10.14.1.12 to-ports=80
add action=dst-nat chain=dstnat comment="Symform Backups" disabled=no dst-port=430
    protocol=tcp to-addresses=10.14.1.3
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
    disabled=yes to-addresses=0.0.0.0
add action=masquerade chain=srcnat disabled=no out-interface=ether1 src-address=\
    10.14.1.0/24
add action=masquerade chain=srcnat disabled=no out-interface=pptp-out1 src-address
    10.0.0.0/8
add action=masquerade chain=srcnat disabled=no out-interface=pptp-out1 src-address
    172.16.0.0/16
add action=masquerade chain=srcnat comment="masquerade hotspot network" disabled=n
    src-address=192.168.254.0/24 to-addresses=0.0.0.0

What about the NAT settings on the NOC router?

Opps sorry, I did not figure there was anything at NOC to affect the flow.

NOC

/ip firewall nat
add action=dst-nat chain=dstnat comment=WebServer disabled=no dst-address=12.X.Y.Z \
    dst-port=22,80,10000 in-interface=ether1 protocol=tcp to-addresses=10.0.0.200
add action=add-src-to-address-list address-list="RDC Users" address-list-timeout=0s chain=\
    dstnat comment="RDC Server for Accounting" disabled=no dst-address=12.X.Y.Z \
    dst-port=13389 protocol=tcp to-addresses=10.0.0.202 to-ports=3389
add action=dst-nat chain=dstnat comment="RDC Server for Accounting" disabled=no dst-address=\
    209.105.228.42 dst-port=13389 in-interface=ether1 protocol=tcp to-addresses=10.0.0.202 \
    to-ports=3389
add action=masquerade chain=srcnat disabled=no

If you didn’t clip that on the cut & paste then it looks as if you have a rule masquerading all traffic…

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…

Thanks for your help on this..!

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…

Actually all of the PPTP connections at the NOC use the same local address of 172.16.0.1

/ppp secret
add caller-id="" comment="TX, Dallas" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP002TX001 profile=default-encryption remote-address=\
    172.16.43.1 routes="10.43.1.0/24 172.16.43.1 1" service=pptp
add caller-id="" comment="AZ, Tempe" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP001AZ001 profile=default-encryption remote-address=\
    172.16.3.3 routes="10.3.3.0/24 172.16.3.3 1" service=pptp
add caller-id="" comment="AZ, Scottsdale" disabled=yes limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP005AZ002 profile=default-encryption \
    remote-address=172.16.3.1 routes="10.3.1.0/24 172.16.3.1 1" service=pptp
add caller-id="" comment="AZ, Glendale" disabled=yes limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP006AZ003 profile=default-encryption \
    remote-address=172.16.3.2 routes="10.3.2.0/24 172.16.3.2 1" service=pptp
add caller-id="" comment="TX, Plano" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP043TX002 profile=default-encryption remote-address=\
    172.16.43.2 routes="10.43.2.0/24 172.16.43.2 1" service=pptp
add caller-id="" comment="IA, Urbandale" disabled=yes limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP015IA001 profile=default-encryption \
    remote-address=172.16.15.1 routes="10.15.1.0/24 172.16.15.1 1" service=pptp
add caller-id="" comment="AZ, Tempe" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP003AZ004 profile=default-encryption remote-address=\
    172.16.3.4 routes="10.3.4.0/24 172.16.3.4 1" service=pptp
add caller-id="" comment="TX, Plano - REMOTE USER" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP99943255 profile=\
    default-encryption remote-address=172.16.255.1 routes="10.43.255.0/24 172.16.255.1 1" service=pptp
add caller-id="" comment="IN, Indianapolis" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP014IN001 profile=default-encryption \
    remote-address=172.16.14.1 routes="10.14.1.0/24 172.16.14.1 1" service=pptp
add caller-id="" comment="TX, Plano - TECH BENCH" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP99943254 profile=default-encryption \
    remote-address=172.16.254.2 routes="10.43.254.0/24 172.16.254.2 1" service=pptp
add caller-id="" comment="IL, Florida" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP021IL002 profile=default routes="" service=any
add caller-id="" comment="IL, Florida" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP021IL003 profile=default routes="" service=any
add caller-id="" comment="INDY REMOTE OFFICE" disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=172.16.0.1 name=PPTP99914255 profile=\
    default-encryption remote-address=172.16.255.2 routes="10.14.255.0/24 172.16.255.2 1" service=pptp

Sorry I forgot to add… The 172.16.255.2 is the PPTP address of the 10.14.255.1 router where I am originating the icmp traffic in the testing.

Please upload the NAT table of this specific router.

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.