Proper routing for lan through verizon private network (GRE) to airlink gateways
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 22.214.171.124 crypto isakmp key AbCdEf01294 address 126.96.36.199 ! ! 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 188.8.131.52 set peer 184.108.40.206 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 220.127.116.11 tunnel destination 18.104.22.168 ! interface Tunnel2 description GRE Tunnel 2 to Verizon Wireless ip address 172.16.200.6 255.255.255.252 tunnel source 22.214.171.124 tunnel destination 126.96.36.199 ! 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 188.8.131.52 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 184.108.40.206 ! ip access-list extended VZW_VPN permit gre host 220.127.116.11 host 18.104.22.168 permit icmp host 22.214.171.124 host 126.96.36.199 permit esp host 188.8.131.52 host 184.108.40.206 permit udp host 220.127.116.11 host 18.104.22.168 eq isakmp permit gre host 22.214.171.124 host 126.96.36.199 permit gre host 188.8.131.52 host 184.108.40.206 ! access-list 23 permit 10.10.10.0 0.0.0.7 ! ! ! control-plane
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 220.127.116.11
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!
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.
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...