SNMP sur IPCop

[aviscdr]

Bonjour.

J'ai récemment installé manuellement un démon snmpd sur plusieurs IPCop.
Je n'ai aucun problème pour accéder aux données SNMP des IPCops situés sur le LAN.

Par contre, il m'est impossible de récupérer les infos depuis les routeurs de mes sites distants (tous IPCop d'origine sans add-ons, LAN to LAN VPN d'origine IPCop).

Si je me connecte en TSE sur le PDC d'un site distant par exemple, il récupère très bien les infos SNMP de l'IPCop local du site distant.

Je vois bien les requetes SNMP entrantes sur ipsec0 via un tcpdump, mais dans le cas d'un site distant je ne vois pas la réponse SNMP.
Mon fichier snmpd.conf est configuré pour écouter sur n'importe quelle IP (avec un netstat ça écoute sur 0.0.0.0).

Je n'ai rien dans les les logs du pare-feu.

Est-ce qu'IPCop bloquerait les paquets SNMP vu qu'ils viennent d'un autre sous-réseau ?
Est-ce qu'il y a une option cachée autrement située que dans le fichier snmpd.conf pour autoriser d'autres sous-reseaux ? pour écouter sur ipsec0 peut-etre ?
Mes modifs dans le fichier hosts.allow ou hosts.deny n'ont rien donné.

Ya t'il d'autres tests à effectuer en plus du tcpdump ?

A titre d'info j'ai utilisé le package suivant: http://www.ipcop-forum.de/forum/viewtopic.php?t=13267&highlight=snmp

Merci d'avance.

[aviscdr]

Si je puis me permettre un petit ...

[aviscdr]

Je reste sans réponse sur ce problème.

Si j'ouvre un accès externe sur le port 161 UDP et que j'interroge le coté rouge du site distant depuis mon LAN, ça fonctionne très bien.

Quand j'interroge le coté vert, ça ne fonctionne pas.
Pourtant, avec le debug d'activé, on voit bien que le démon snmpd reçoit les requêtes et envoi les réponses.
Elles se perdent en route...

J'ai l'impression qu'il manque une route, ou un tunnel supplémentaire, ou encore une règle iptables...

Des avis ?

[Gesp]

Essaye sur la liste ipcop-user.

Tu as plus de chances d'être en contact d'autres utilisateurs de l'add-on.

[aviscdr]

Merci je vais tenter ma chance. Je vous tiens au jus...

[aviscdr]

Bonjour.

J'ai repris le problème hier après l'avoir un peu mis en pause, et j'ai trouvé ceci de très interressant:

Why can't I query SNMP, use syslog, NTP, or other services initiated by the firewall itself over IPsec VPN?

Due to the way IPsec tunnels are kludged into the FreeBSD kernel, any
traffic *initiated* by m0n0wall to go through an IPsec tunnel gets the
wrong source IP (and typically doesn't go through the tunnel at all as a
result). Theoretically this *shouldn't* be an issue for the *server* side
of SNMP, but perhaps the server has a bug (well, deficiency, at least)
where it doesn't send the response out through a socket bound to the
request packet.

You can fake it out by adding a bogus static route to the remote end of
the tunnel via the m0n0wall's LAN IP (assuming that's within the near-end
tunnel range). A good test is to see whether you can ping something at
the remote end of the tunnel (e.g. the SNMP remote) *from* the m0n0wall.

There's an annoying but mostly harmless side-effect to this - every LAN
packet to the tunnel elicits a no-change ICMP Redirect.

To do this, click "Static Routes" in the webGUI. Click the + to add a static route. In the Interface box, choose LAN, for destination network, enter the remote end VPN subnet, and for the gateway put in the LAN IP address of your local m0n0wall.

J'ai tenté de le transposer sur IPCop mais malgré différentes routes, je n'arrive pas à grand chose (sinon à gener les pings ou le SHH qui eux passent très bien...)

Est-ce que quelqu'un aurait une idée ? Une route à proposer ?

En gros:

Client SNMP === [Green1]IPCop[Red1] === Internet === [Red2]IPCop[Green2] === Réseau distant

Je cherche à interroger le démon SNMP sur [Green2] depuis Client SNMP à travers un VPN IPSec. Les pings fonctionnent, la requete SNMP est bien réceptionnée, mais pas de réponse. L'interrogation de [Green2] depuis Réseau distant fonctionne. L'interrogation d'un poste sur Réseau distant depuis Client SNMP à travers le VPN fonctionne.

[aviscdr]

NE CHERCHEZ PLUS

J'ai trouvé. Il suffit de faire du POSTROUTING

Sur l'IPCop distant qu'on veut monitorer:

$ iptables -t nat -A POSTROUTING -d 192.168.200.0/24 -p all -j SNAT --to-source 192.168.207.99

192.168.200.0/24 => Sous-réseau LOCAL du Client SNMP
192.168.207.99 => Patte verte de l'IPCop distant (sur mon schéma c'est Green2).

Grosso-merdo, on fait croire à IPCop que l'initialisation des connexions à destination de 192.168.200.0/24 vient de la patte LAN, ce qui lui permet d'emprunter ipsec0 pour envoyer son bazar (si j'ai bien tout suivi)

Pour l'instant, ça roule

Note: Autant de recherches pour aboutir à ... une ligne. Le réseau, on aime ou on aime pas