Check_ping options not built in - use ping?

[Dave Stubbs]

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.

Oops!  The Txt diagram is a bit mangled.  Let me re-send.

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?  :-)

Dave...



-------------------------------------------------------
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