Tech Support Guy banner

Some advice on Routing over Verizon PN GRE

1716 Views 7 Replies 2 Participants Last post by  zx10guy
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 address 99.101.15.99
crypto isakmp key 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!

< edited out the key - MOD - Etaf >
See less See more
Status
Not open for further replies.
1 - 8 of 8 Posts
If I understand correctly, the 192.168.1.0 network is the private address for the remote side. You shouldn't need to put in a static route to get there. The 2911 is configured to do BGP routing. You need to do a.....show ip route.....command to see what your local 2911 route table looks like. It should already have a route entry for the 192.168.1.0 network and what the next hop is. If it doesn't show up, there's a break down in the BGP routing protocol between locations. You need to then check to see if something got misconfigured on the other end. The line you're looking for at the other end is....network 192.168.1.0.....under the.......router BGP [router process number].....command.

Also you need to edit your config above. I can see the clear text passphrase you are using to establish your VPN tunnels.
Looks like someone cleaned it up for me but AbCdEf01294 was not real nor were any of the public IP's, I modified it from the real key and IP's (if that is the part you were referring to).
Yes that is correct, 192.168.1 is the remote side. I kind of though the same thing with the BGP being used. Unfortunately the other side of the tunnel is verizon, it will probably take a phone call and 3 hours on hold to check status on their side. I am looking forward to getting out there Tuesday to check the installed routes and use the tons of tools I have learned reading over the last several days.

I would think the fact that I can ping with a local machines subnet opened up to 255.255.0.0 would say something about what is wrong. Tunnel must be up for sure. So from a basic look the setup above should work perfectly fine for direct access to the IP's on the 192.168.1 network from the 192.168.11 side?
Yes. It seems the tunnel is up and moving traffic. Who has ownership of the router at the other end of the GRE tunnel on 172.16.200.1? If you do, you should be able to remote into that router and check the configs. That's provided the router has been set up to accept Telnet or SSH sessions.

I didn't know you had cleaned up the config. Good for you for recognizing that but adding in the dummy preshared keys is unnecessary for anyone who knows what they're looking at in the config. I could only assume you inadvertently left them in.
Verizon owns the routers at the other end, I would probably have to spend hours on the phone with them to get any sort of answer. But if my route tables from BGP don't look right I will have to contact them I suppose.

Just trying to be thorough on the config, If I had taken them out I would have surely gotten an answer from someone that would say "no wonder its not working, you aren't logging in to the tunnel properly" LOL

I have to tell you, I have been sucked in to the networking stuff after many years of just brushing by it, never really realized it but it is very similar to the PLC programming I do, seems as if there are a million ways to skin a cat so to speak. I read one thing about one command, then read another that presents a completely different way of going about the same thing, not to mention the 400 things that can interact or override a command you have already enabled. Smugly thought I could be speaking "the language" in a matter of a week, but I can see this field is one like mine, where it is a constant learning experience.
See less See more
This is something many people don't understand about the world of networking. Networking is very broad. There's so much to networking and why there are so many sub specialties. You can specialize in switching, routing, wireless, voice, application delivery, security, data centers, and the list goes on. Even within the sub specialties, there are more specializations. I've been doing networking for 10+ years and I'm constantly learning things. I also don't consider myself an expert compared to some of my peers. Right now there's a how new paradigm in networking called SDN (software defined networking). At first, SDN was someone's science project. Now it has some legs under it with the evolution of Open Flow and all the manufacturers putting real development effort behind it.
It's exactly why I like the technology fields (and hate it at times) always something new and some sort of never seen before problem (sorry I mean challenge!), it just has surprised me how engrossed I became during this project after many years of just passing off the networking aspect of my job to the IT guys. But I have to tell you, getting most IT departments to understand and work with me on the very specialized aspect of automation networking, has been mostly difficult to say the least. When I tell them how "open" the automation portion of the network has to be they tend to cringe and fret at the lack of control they get to maintain over that section of the network.
The IT people you describe are what I run into on a daily basis. Makes me really wonder if these people actually belong in IT. To me the magic about IT is how things develop and change (usually for the better). If people like the ones you describe actually had control over how IT advances, we'd all still be on Thin Net/Thick Net and Token Ring.
1 - 8 of 8 Posts
Status
Not open for further replies.
Top