Community
Command Central
MVP Program
Monthly Mission
Blogs
Groups
Events
Media Vault
Products
Observability
Network Management
Application Management
IT Security
IT Service Management
System Management
Database Management
Content Exchange
SolarWinds Platform
Server & Application Monitor
Database Performance Analyzer
Server Configuration Monitor
Network Performance Monitor
Network Configuration Manager
SQL Sentry
Web Help Desk
Free Tools & Trials
Store
Home
Products
Network Performance Monitor (NPM)
Orion across VPN
ceclark
We're looking at monitoring customer networks and the only viable option I see is to do it through a VPN tunnel. How is that working for those of you who monitor through a tunnel? Can any verify if the next version will allow you to select a custom port for SNMP polling?
Find more posts tagged with
Accepted answers
All comments
Network_Guru
We are monitoring 200 remote Cisco routers setup with EZ-VPN to a VPN concentrator in Lan extension mode. It's working fine (we don't monitor the tunnels, just the remote LAN & WAN interface).
-=Cheers=-
NG
andersond
Not sure that I really follow you on your question. I monitor many remote sites out of a centralized Data Center. We generally have a T1 circuit or better to the remote sites. I do however connect into one of my sites via a VPN tunnel. I use Orion to poll devices on the other end and have metrics as to how often the VPN tunnel is online/offline.
Unfortunately I am not monitoring the actual VPN tunnel itself. My alerts are based on monitoring a device within the remote site. If I loose connectivity to the remote device, then I know the VPN tunnel went down. The other draw back is I don't have any metrics on how much traffic is being passed over the VPN tunnel.
Here is another sinario that maybe someone else has worked on:
VPN BACKUP TUNNELS and VLANs
As stated above I have a primary WAN link to my remote offices. I monitor each of these links to see how much traffic we are passing and see if there are any errors. Also use this to see our "up time" on the WAN circuit to compare to vendors statistics.
Each remote office also has a dedicated Internet connection and there is a VPN tunnel always active (using a higher cost RIP route).
static.flickr.com/.../199539812_3e35171fe4_o.jpg
If the WAN link to a remote office goes offline, the VPN tunnel will start passing traffic and the remote site will come back online. This means I can now route through another path to my WAN router at the remote site. Solarwinds now reports that the remote device is back online because it has connectivity back into the device. With this setup I can still monitor my remote sites up/down time based on the WAN Interface of the remote router.
VLANS
This gets even more complicated as we do not have dedicated routers in some links as shown above. We are using routing switches that have VLAN segments to seperate traffic to remote sites. I can't monitor Interface status in the main site with Orion because the link is a single ethernet port with multiple VLANs assigned tunneling to each remote site (point A). Monitoring that port will show the total traffic to all remote sites because multiple VLANs are assigned to that single port.
VLAN's don't report the same type of statistics that normal Interfaces do, so there is no way to monitor from the close side if the WAN link goes down. To monitor the amount of traffic IN/OUT of NY lets say - I have to monitor point D.
When I run reports on uptime/downtime for devices my results are now skewed as the VPN tunnel kept connectivity online to the office. (Yes the report is correct that the devices in the remote site were not really offline because there was a slow link established to them.) My main goal of reporting the uptime of the Primary WAN is now unacheivable.
Anyone have any suggestions/thoughts?
Solarwinds - the WAN is getting more complicated as Metro Ethernet becomes much cheaper. These types of deployments (if they are not happening readily now) will become more prevelent in the near future. Some guidance where would be appriciated.
Troy8181
We monitor all of our 78 clients through VPN tunnels and it works fine. The only issue is, of course, if your ASA or VPN concentrator has issues, or if there is an outage with one of the client ISP's. They can actually show down when in fact they are fine. We compensate for this by not alerting on the first missed ping and setting the Node Warning Interval to 180 seconds before alerting the 1st level. This allows 18 extra pings before it shows as being down. You would want to play with these numbers to meet your requirements but it's very easy to do. We chose overkill to make sure we have very few false positives.
ceclark
Thank you all for the good info.
iunderwo
I suspect that the original intent was just to port-forward a range of ports to devices that need monitoring. For example, 10 devices behind a single NAT gateway, and sending one port to a different internal host.
Currently, this is not possible and as properly suspected, a VPN tunnel is required.
// Ian Underwood - Network Engineering
// Boston Stock Exchange
Quick Links
All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of
