Check_ping options not built in - use ping?

[Andreas Ericsson]

Dave Stubbs wrote:
> Andreas Ericsson wrote:
> 
>> Dave Stubbs wrote:
>>
>>> Hello all,
>>>
>>> I need to be able to specify a source address for check_ping when 
>>> querying certain hosts.  The ping command has this option with -I 
>>> (see man ping).  Is there any way to do this with check_ping?  Does 
>>> check_ping have the ping command built into itself?  Or does it call 
>>> the ping binary?
>>>
>>
>> check_ping calls the ping binary. check_icmp has it built-in. It's 
>> fairly easy to write such spoofing code when one has access to raw 
>> sockets, but I never saw the need for it in a good honest application. 
>> If you could sketch out the basics of your network setup and provide a 
>> decent reason why the source IP should be user-definable I might add 
>> it to check_icmp.
>>
> Wow - now that's a quick response!
> 
> Basically the main reason for this request is OpenSWAN.  I happen to run 
> Nagios on the same machine that is my OpenSWAN gateway.  A simple 
> diagram is like this:
> 
> Europe LAN-------- EuGate ---- Internet ---- NAGate ---- North America 
> LAN    Europe Private IP                                        North 
> America Priv IP
> 10.1.1.0/24                                              10.2.1.0/24
> 
> Of course, on both the North America and Europe side, there are more 
> routers on the LANs which connect to other networks.
> 
> EuGate has a private IP of 10.1.1.1 and Public IP 212.3.3.3 (for instance)
> NAGate has a private IP of 10.2.1.1 and Public IP 24.3.3.3(for instance)
> 
> Nagios runs on the NAGate machine, which does IPSec policy-based routing 
> to send packets through the tunnel from the North America LAN to the 
> Europe LAN and back:
> 
> EuGate:  Source Traffic 10.1.1.0/24  Destination 10.2.1.0/24 - Tunnel
> NAGate:  Source Traffic 10.2.1.0/24  Destination 10.2.2.0/24 - Tunnel
> 
> The IPSec policy applies to the Private IPs on either end.
> BUT here's where the problem begins.  Because OpenSWAN uses IPSec 
> policy-based routing instead of normal IP routing (with proper 
> interfaces) the routes in this system look weird, but work ok.
> 
> For instance, the route on NAGate that sends traffic through the tunnel 
> is like this:
> 
> Dst:  10.1.1.0
> Mask: 255.255.255.0
> GW:  24.3.3.1 - NAGate's ISP
> 
> If you just look at that from a normal network routing perspective, you 
> would say that it would never work.  There's no way the Europe-bound 
> traffic would ever make it to the Europe LAN by simply passing it to the 
> ISP.  But at this point the IPSec policy-based routing takes over, and 
> redirects the traffic through the tunnel (which indeed still goes right 
> to the ISP on the way to Europe)
> 
> Soooooo...  If I send a PING command from NAGate to the EuGate private 
> IP or any other private IP on the Europe LAN, such as some host at 
> 10.1.1.23, the originating address on the ping is the PUBLIC address of 
> NAGate - 24.3.3.3.  Because the originating address doesn't match the 
> IPSec routing policy, it doesn't get encrypted and sent through the tunnel.
> 
> BUT (here's the important part) if I specify my ping on the NAGate host 
> like this:
> 
> ping -I eth1 10.1.1.23 (eth1 is the private interface 10.2.1.1) the 
> pings go through ok because their source address now fits the IPSec policy.
> 
> If I was running Nagios on any other host on the network except the 
> IPSec gateways, this wouldn't be a problem, but because it runs ON the 
> gateway itself, the challenge arises.
> 
> Is this non-convoluted enough to justify the change?  :-)
> 

Yes, but it's a fairly specific situation. I'd suggest you change the 
ping command in config.h after having run ./configure. You can then set 
the parameters to whatever you like. If you ever move your nagios 
installation to another gateway (or change IP) you'd have to do the same 
again.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null