Proper routing for lan through verizon private network (GRE) to airlink gateways

Question

Okay, I give up, and think I have done my due diligence (I have been engrossed and fascinated spending many more hours than allotted to try and learn some of the finer details).  Time for some advice.  My usual trade is controls engineering which generally require only basic knowledge of networking principals.  However I recently took a job to integrate 100 or so lift stations scattered around a county into a central SCADA system.  I decided to use cellular technology to connect these remote sites back to the main SCADA system.  Well the infrastructure is now in and it’s time to get these things talking.  Basic topology description is as follows:  Each remote site has an Airlink LS300 gateway.  Attached to the gateway via Ethernet is a system controller that I will be polling via Modbus TCP from the main SCADA system.  The Airlinks are provisioned by Verizon utilizing a private network with static IP's.  This private networks address is 192.168.1.0/24.  Back at the central office the SCADA computer is sitting behind a Cisco 2911.  The LAN address of the central office is 192.168.11.0/24.  The 2911 is utilizing GRE tunnels that terminate with Verizon.  The original turn up was done with another contractor that did a basic config of the router which you will find below.  As it stands now I am pretty confident the tunnels are up and working (if I change a local computers subnet to 255.255.0.0 I can surprisingly reach the airlinks in the field), but this is obviously not the right way to solve the problem, not to mention I was unable to successfully poll the end devices on the other side of the Airlinks.  I think I understand just about every part of the config below and think it is just missing a few items to be complete.  I would greatly appreciate anyone’s help in getting this set up correctly.  I also have a few questions about the set up that still don’t make sense to me, you will find them below the config.  Thanks in advance.
no aaa new-model
ip cef
ip dhcp excluded-address 10.10.10.1
ip dhcp pool ccp-pool
 import all
 network 10.10.10.0 255.255.255.248
 default-router 10.10.10.1 
 lease 0 2
ip domain name yourdomain.com
no ipv6 cef
multilink bundle-name authenticated
username cisco privilege 15 one-time secret 
redundancy
crypto isakmp policy 1
encr 3des
hash md5
 authentication pre-share
 group 2
crypto isakmp key AbCdEf01294 address 99.101.15.99  
crypto isakmp key AbCdEf01294 address 99.100.14.88 
crypto ipsec transform-set VZW_TSET esp-3des esp-md5-hmac 
mode transport
crypto map VZW_VPNTUNNEL 1 ipsec-isakmp 
 description Verizon Wireless Tunnel
 set peer 99.101.15.99
 set peer 99.100.14.88
 set transform-set VZW_TSET 
 match address VZW_VPN
interface Tunnel1
 description GRE Tunnel to Verizon Wireless
 ip address 172.16.200.2 255.255.255.252
 tunnel source 22.20.19.18
 tunnel destination 99.101.15.99
interface Tunnel2
description GRE Tunnel 2 to Verizon Wireless
 ip address 172.16.200.6 255.255.255.252
 tunnel source 22.20.19.18
 tunnel destination 99.100.14.88
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
interface GigabitEthernet0/0
 description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
 ip address 10.10.10.1 255.255.255.248
 shutdown
 duplex auto
 speed auto
interface GigabitEthernet0/1
 ip address 192.168.11.1 255.255.255.0
 duplex auto
 speed auto
interface GigabitEthernet0/2
 ip address 22.20.19.18 255.255.255.0
duplex full
 speed 100
 crypto map VZW_VPNTUNNEL
router bgp 65505
 bgp log-neighbor-changes
 network 0.0.0.0
 network 192.168.11.0
 neighbor 172.16.200.1 remote-as 6167
 neighbor 172.16.200.5 remote-as 6167
ip forward-protocol nd
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip route 0.0.0.0 0.0.0.0 22.20.19.19
ip access-list extended VZW_VPN
 permit gre host 99.101.15.99 host 22.20.19.18
 permit icmp host 99.101.15.99 host 22.20.19.18
 permit esp host 99.101.15.99 host 22.20.19.18
 permit udp host 99.101.15.99 host 22.20.19.18 eq isakmp
 permit gre host 22.20.19.18 host 99.101.15.99
 permit gre host 22.20.19.18 host 99.100.14.88
access-list 23 permit 10.10.10.0 0.0.0.7
control-plane
end
So after spending countless hours analyzing every portion of this,  I think that adding one line to this will get it going (or at least closer).
ip route 192.168.1.0 255.255.0.0 22.20.19.19
That should allow my internal LAN to reach the Airlink gateways on the other side of the tunnel (I think)
Now for a couple of questions for those that are still actually hanging around.
#1 what is the purpose of the Ethernet address assigned to each tunnel?  I only see them being used in the BGP section where they are receiving routing tables from the Verizon side (is that correct?).  Why wouldn't or couldn't you just use the physical Ethernet address interface in its place (in the BGP section)?
#2 is the config above correct in pointing the default route to the physical Ethernet address?  Does that force the packets into the tunnel, or shouldn’t you be pointing it towards the tunnel IP's (172.16.200.2)?  If the config above is correct then I should not need to add the route I described above as if I ping out to 192.168.1.X that should catch it and force it into the tunnel where Verizon would pick it up and know how to get it to its destination??
#3 Will I need to add another permit to the VZW_VPN for TCP as in the end I need to be able to poll via Modbus which uses port 502 TCP.  Or is TCP implicit in some way with the GRE permit?
 I actually have alot more questions, but I will keep reading for now.
I really appreciate the time you all took to trudge through this.  Also please feel free to point anything else out that I may have missed or that can be improved.  Have a great day!

Answer 1

My first comment is that you have two posts in this forum and as far as I can tell they are exact duplicates, other than changing the title of the posts. It is better to figure what you want to ask and then to ask once.
My second comment is that you have given us information about your central site. At some point we may also need some information about what is at the remote and how that is set up. But for now we will deal with what we know about your site.
Before I deal with your specific questions I will comment that if you are able to access the remote airlinks that it is a pretty good indicator that the tunnels are probably working. But to understand the significance of this it would help if you clarify for us what address is on the local computer when you change the subnet to 255.255.0.0.
Also what you have shown us allows us to see that BGP is configured but provides no insight into whether BGP is working or now. It would provide helpful information if you would post the output of show ip bgp sum.
So to address your specific questions:
You suggest that adding a static route for 192.168.1.0 might be part of the solution. But we have no information about what that network is or its significance. So we have no way to know whether the static route would help or not. But my guess (based on very scant information and therefore based mostly on assumptions) is that if BGP is working correctly that the static route is not needed.
1) asks about an Ethernet address on the tunnel. I assume that you really meant to ask about the IP address assigned to the tunnel. The reason that the tunnel needs it own IP address is that we want a unique subnet assigned to the tunnel. If we used the address from the physical interface as you suggest then both tunnels would have the same address and that implies that they both connect to the same place, and that assumption is not correct.
2) Yes it is correct to point the default route to the IP address that is the next hop from the Ethernet interface. You might want to have a route pointing at the tunnel address for remote subnets reached via the tunnel. But in looking at the config and trying to understand what was intended it is pretty obvious that running BGP over the tunnel is intended to learn the remote addresses over the tunnel and therefore there is no need for static routes for the remote resources.
3) You should not need an additional permit for TCP 402. The TCP packet will be carried through the tunnel and the access list you are referring to will see the packet will modbus polling as GRE traffic and not as TCP traffic.
HTH
Rick