bypasser un VPN par défaut (en le gardant sur IP voulus)

[Polo35230]

En VPN SSL, c'est le serveur VPN qui décide si tout les flux passent par le VPN ou pas, et tu ne peux rien y changer!

Possible. (Mais ce serait pas plutôt le client VPN du Mac?)
Les routes sont bonnes, mais il faut que le Mac jongle entre ses deux adresses IP (en 10 et en 192) selon que la comm passe par le VPN, ou pas.
Seule une trace pourrait donner l'explication...

 

[ccciolll]

Et alors comment faire une trace ?

Et comment déterminer si le VPN est SSL ou IPsec ?

---------- Nouveau message ajouté à 10h56 ---------- Le message précédent a été envoyé à 10h53 ----------

EDIT : et, pour répondre à la remarque : en effet, pour revenir poster sur macgé j'avais quitté le VPN dont j'avais deleté la route.

 

[Polo35230]

Et alors comment faire une trace ?

Il faut activer ton VPN
Puis lancer trois fenêtres Terminal.
Dans la première, tu tapes la commande:
sudo tcpdump -c 5 -i en0 host 8.8.8.8 (c'est pour capturer 5 lignes de la trace avec la mchine 8.8.8.8 (c'est le DNS de Google) sur l'interface ethernet
Dans la deuxième:
sudo tcpdump -c 5 -i jnc0 host 8.8.8.8 (c'est pour capturer 5 lignes de la trace avec la mchine 8.8.8.8 (c'est le DNS de Google) sur l'interface VPN
Dans la troisième
ping -c 5 8.8.8.8

En principe, ça défilera, dans une des deux premières fenêtres Terminal.
On verra alors par où on sort, et quelle adresse IP le Mac utilise (10 ou 192).

Ça ne règlera pas le pb, mais on devrait savoir pourquoi ça ne marche pas...
Pour le fun, quoi...

Et comment déterminer si le VPN est SSL ou IPsec ?

En principe, quand tu as paramètré ton VPN, tu as dû choisir un protocole, du genre OpenVPN, SSH, PPTP, etc...
C'est ce qui nous dira ce que tu utilises.

 

[drs]

Non vu la capture d'écran que tu as donné, il s'agit du vpn ssl network connect.

 

[ccciolll]

En principe, ça défilera, dans une des deux premières fenêtres Terminal.
On verra alors par où on sort, et quelle adresse IP le Mac utilise (10 ou 192).

Ça ne règlera pas le pb, mais on devrait savoir pourquoi ça ne marche pas...

J'ai fait le test comme tu l'as indiqué, sans rien faire d'autre (pas de sudo delete route etc) et c'est dans la fenêtre jnc0 que ça a bougé.
(j'ai copié les résultats si nécessaire)

Faut-il refaire un test après avoir fait un sudo delete route ?

En principe, quand tu as paramètré ton VPN, tu as dû choisir un protocole, du genre OpenVPN, SSH, PPTP, etc...
C'est ce qui nous dira ce que tu utilises.

Je n'ai rien paramétré…
J'ai dû réinstaller javascript, et ensuite aller sur le site qu'on m'a indiqué. (https://vpn.xxxxxx.com/dana-na/auth/url_default/welcome.cgi) où j'avais la même chose que dans ma capture du network connect (welcome to xxxxxx secure VPN…), là j'ai du saisir mon identifiant et mot de passe. Ensuite il met « chargement de l'aplet », puis affiche une page comme ceci :
Uploaded with ImageShack.us

Là je dois cliquer sur Démarrer et ça lance ceci :
Uploaded with ImageShack.us

Puis ça fini par ouvrir Network Connect :
Uploaded with ImageShack.us

Donc je pense que c'est à ce moment-là que tout se paramètre tout seul…

Mais il est probablement possible de retrouver qqpart les réglages qu'il a fait ?


Ah, et aussi, autre info peut-être intéressante, quand je quitte le VPN, il n'est pas rare que je perde complètement ma connexion et sois obligé de me connecter à la livebox et lui demander de redémarrer, bien qu'elle affiche toujours que la connexion internet est activée.

 

[Polo35230]

J'ai fait le test comme tu l'as indiqué, sans rien faire d'autre (pas de sudo delete route etc) et c'est dans la fenêtre jnc0 que ça a bougé.
(j'ai copié les résultats si nécessaire)

Faut-il refaire un test après avoir fait un sudo delete route ?

Tu raisonnes juste.
Normal qu'on sorte par jnc0, J'avais oublié le delete de la route...
Donc, on reprend...

Il faut activer ton VPN
puis deleter la route par défaut qu'il a créée vers le VPN
sudo route delete default 10.24.251.163
Puis lancer trois fenêtres Terminal.
Dans la première, tu tapes la commande:
sudo tcpdump -c 5 -i en0 host 8.8.8.8 (c'est pour capturer 5 lignes de la trace avec la mchine 8.8.8.8 (c'est le DNS de Google) sur l'interface ethernet
Dans la deuxième:
sudo tcpdump -c 5 -i jnc0 host 8.8.8.8 (c'est pour capturer 5 lignes de la trace avec la mchine 8.8.8.8 (c'est le DNS de Google) sur l'interface VPN
Dans la troisième
ping -c 5 8.8.8.8

On devrait normalement sortir par en0.
Dans la trace, on verra si le Mac a pris une adresse en 10 ou en 192. On saura alors pourquoi ça ne marche pas.

JDonc je pense que c'est à ce moment-là que tout se paramètre tout seul…
Mais il est probablement possible de retrouver qqpart les réglages qu'il a fait ?

Je crois que tu n'as rien paramétré, car le VPN que tu utilises n'est pas un VPN du marché.
C'est pas le VPN privé d'une université américaine?

drs a l'air sûr de lui, quant aux serveurs VPN SSL. Il a peut-être (surement) raison...
Mais sa piste de remplacer le clent VPN SSL par un client IPSec sera difficile a mettre en oeuvre si on ne peut pas paramètrer le clent.
A moins que,... drs, si tu as une piste?

 

[drs]

je suis absolument sûr de moi

Il s'agit en effet d'un VPN SSL, irremplacable par un VPN IPsec.

On a le même problème avec le VPN IPSec de Cisco. Le fait de tout envoyer ou pas dans le tunnel ne dépend pas du client (donc toi), mais du paramétrage du serveur.
Pour preuve, va sur l'iphone, et compare le paramétrage d'un VPN L2TP et celui de l'IPSec: dans le premier tu as une case nommée "tout envoyer" et pas dans l'autre.
Cette case permet de savoir si on envoie tout le flux dans le tunnel ou pas, ou bien si on envoie dans le tunnel uniquement le flux qui doit y passer (et donc pas les flux locaux ni internet).


Dans ma boite, il y a les deux accès, VPN SSL ou VPN IPSec, donc j'ai pu passer à l'IPSec sans problème, puisque c'est prévu. Et en me connectant avec le VPN SSL, j'ai le même souci que toi, à savoir que mes flux internet veulent passer par le tunnel.

En fait, ce qu'il faut comprendre, c'est que le serveur VPN SSL et le serveur IPSec ne sont pas les mêmes, ce sont deux protocoles différents. On peut faire l'un ou l'autre, ou les deux si c'est prévu.

Malheureusement pour toi, il n'y ici aucune solution. Tu peux écrire les routes que tu veux, tout continuera à passer dans le tunnel.
Le problème vient, encore une fois, du fait que le routage est géré par le distant et non pas en local.

J'espère que mon explication est assez claire, parce que c'est pas très simple à expliquer

 

[ccciolll]

Ehhh m*****rde…

J'ai passé 10 minutes à écrire une réponse détaillée, mais comme je venais de faire le test, je n'avais plus de connexion, et quand j'ai validé ma réponse, elle s'eszt perdue dans les limbes.

Pffff, plus qu'à tout refaire. Bon, je vais prendre un café d''abord.

---------- Nouveau message ajouté à 10h39 ---------- Le message précédent a été envoyé à 10h25 ----------

Bon, je disais donc.

j'ai fait les tests.

il a juste fallu corriger un peu car entre temps l'url du tunnel avait changé (mais heureusement, je commence à apprendre un tout petit peu et j'avais fait un netstat avant le delete et constaté que l'url en .163 n'existait plus.)

Donc, VPN lancé et route deleté, j'obtiens ceci :

EN0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes

JNC0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on jnc0, link-type NULL (BSD loopback), capture size 65535 bytes

PING
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Donc apparemment rien ne passe.
JNC0 a aussi ajouté plus tard (peut-être après que je l'ai déconnecté, je ne sais pas) :
tcpdump: pcap_loop: read: Device not configured
0 packets captured
0 packets received by filter
0 packets dropped by kernel


Et en réponse à drs je comprends tout à fait le fond de ce que tu dis : c'est le serveur VPN qui décidé tout à ma place et à priori je ne peux rien faire pour y échapper.

Sauf peut-être faire 2 sessions sur mon poste (l'une en VPN, l'autre en normal) et sauter de l'une à l'autre, non ?
Ou alors avoir 2 ordis, un pour le travail, et l'autre pour la connexion à ces 3 serveurs (quitte à mettre un PC de daube, voire un portable) et les relier ensuite via la box. Mais ça me pose un pb de place sur mon bureau (et puis aussi ça me pose le problème d'obtenir un 2e ordi de mon employeur, même un PC de daube c'est pas gagné).

 

[Polo35230]

C'est encore pire que ce que je pensais...
J'étais quasiment sûr de voir une trace , mais avec la mauvaise adresse source. Mais non, rien.
Ça veut dire que le client VNP prend complètement la main sur le réseau.
Il n'a plus sa route par défaut, mais il rend celle qui va sur la Box inutilisable.
Chais pas comment c'est possible... Drs?
Pour moi, le routage aurait dû prendre le dessus sur le client VPN...

Perso, sur des routeurs (cisco également), j'ai fait cohabiter des Tunnels (GRE) et du routage classique sur une même interface physique.
J'ai bien peur que ton pb n'ait pas de solution.
A moins que sur le forum, quelqu'un ait une idée de génie?

Sauf peut-être faire 2 sessions sur mon poste (l'une en VPN, l'autre en normal) et sauter de l'une à l'autre, non ?

J'ai l'impression que les tables de routages sont communes (d'une session à l'autre)
Mais c'est une bonne idée. A tester...
Autrement, à l'interieur d'une même session utilisateur, il faut jongler entre l'actvation et la désactivation du VPN. Pas pratique.
En tout cas, je vois que tu t'accroches!

 

[ccciolll]

Oui, je m'accroche vu les désagréments que me pose ce VPN lorsqu'il est activé.

Je testerai avec plusieurs sessions quand j'aurais un petit bout de temps.

 

[ccciolll]

Bon, j'ai tenté en créant un deuxième compte utilisateur et en utilisant la permutation rapide.

Donc ça ne marche pas. J'ai activé le VPN sur la nouvelle session, puis suis revenu sur la principale, qui apparemment tirait la langue, et un netstat a confirmé que je passais bien en VPN forcé, bien que Network Connect soit désactivé sur ma session principale.

Pas de solution de ce côté là, donc (ou alors pas comme je m'y suis pris).

par contre, ça ma donné l'occasion de constater que Network Connect que je supposaisi être un logiciel d'origine du mac est en fait installé par le serveur VPN au moment de la première connexion.

Il y a peut-être à creuser de ce côté ? Peut-être que le Network Connect qu'ils m'installent est bridé et qu'il faudrait que j'en trouve une version originale complète avec laquelle je pourrais choisir entre prendre le tunnel ou pas.

Sinon, autre truc, j'ai constaté dans les réglages de la livebox (une livebox pro V2 sagem) qu'on peut paramétrer, dans les réglages avancés, des trucs VPN (parmi toute une ribambelle de choix tous plus obscurs les uns que les autres pour moi : DHCP, NAT/PAT, DNS, NTP, UPnP, Pare-feu, DMZ, DynDNS, Routage…).

Peut-être pourrait-on trouver une solution de ce côté-là (même si je ne pense pas qu'en montant sur une plus grande échelle on soit en mesure de régler des plus petits détails).

Ça me fait penser qu'il faudra qu'un jour je me penche aussi sur la notion de pare-feu (est-il activé par défaut, comment le paramétrer, tout ça, mais pour ça je pense que je trouverai les réponses sur internet, ça n'a rien de spécifique).

 

[Polo35230]

Peut-être pourrait-on trouver une solution de ce côté-là (même si je ne pense pas qu'en montant sur une plus grande échelle on soit en mesure de régler des plus petits détails).
ique).

Je ne pense pas qu'on puisse trouver une solution via la box.
La Livebox pro intègre bien un VPN, mais c'est un serveur VPN. C'est à dire que la box offre la possibilité à des utilisateurs nomades disposant dun client VPN (et par toi autorisés...) à se connecter sur ton réseau local
C'est pile l'inverse de ce que tu veux faire.

 

[ccciolll]

OK, rien à voir alors.

Bon, sinon, j'ai fait le test (un netstat -r). avec un 2e ordi branché sur la box.

Je conserve bien un accès libre via livebox.home sur le 2e ordi quand le 1er est branché au VPN.

Donc la solution 2 ordis fonctionnerait (reste les pb matériels que j'ai évoqués).

Du coup, ça m'a donné une autre idée : mon MacPro possède 2 prises ethernet.
Ne pourrais je pas alors mettre 2 câbles de ces 2 prises ethernet vers 2 prises de la box, et sauter d'une connexion à l'autre ?

Bon, je ne sais pas dans quelle mesure c'est réalisable, et pour le tester concrètement, il faudrait que je tire un 2e câble, donc je vais pas faire ça dans l'heure. Mais bon, pourquoi bas.

Qu'en dites-vous ? Ça vous parait faisable ?

 

[Polo35230]

Donc la solution 2 ordis fonctionnerait (reste les pb matériels que j'ai évoqués).

Oui, mais ça fait riche, comme solution...
Activer et désactiver le VPN est quand même plus simple, non?
Avant d'en arriver là, sauf si ton VPN est un VPN privé, la solution d'essayer un autre client VPN public (IpSec, comme l'a dit Drs) s'impose.

Du coup, ça m'a donné une autre idée : mon MacPro possède 2 prises ethernet.
Ne pourrais je pas alors mettre 2 câbles de ces 2 prises ethernet vers 2 prises de la box, et sauter d'une connexion à l'autre ?
Bon, je ne sais pas dans quelle mesure c'est réalisable, et pour le tester concrètement, il faudrait que je tire un 2e câble, donc je vais pas faire ça dans l'heure. Mais bon, pourquoi bas.
Qu'en dites-vous ? Ça vous parait faisable ?

Alors, tout de suite, ça m'a parru être une idée géniale, mais vu les tests précédents, on va retomber sur le pb de la route par défaut...
Le pb est lié au routage, et pas à la configuration de l'interface (enfin, je crois)

Il y a peut-être une solution via le routage par interface, avec les deux connexions ethernet établies simultanément.
A creuser...

 

[ccciolll]

Oui, mais ça fait riche, comme solution...
Activer et désactiver le VPN est quand même plus simple, non?

Riche ? J'aurai plutôt qualifié cette solution d'encombrante. Mais les deux termes se rejoignent souvent, c'est vrai

Ben activer et désactiver génère plusieurs problèmes.
Déjà, comme je disais, parfois ça me plante la connexion, voire le finder, voire même tous le mac (je dois peut-être respecter une procédure de déconnexion plutôt que de faire direct un pomme-Q sur Network Connect.

Et puis je m'en sers pour me connecter, entre autres, à un serveur de fichier installé dans une zone industrielle où ils n'ont apparemment pas l'ADSL (en tout cas pas le haut-débit) et rien que pour afficher les dossiers à la racine du serveur, c'est plusieurs minutes de rame. J'ai donc créé des symlink (alias allégés) des fichiers les plus couramment utilisés, mais même comme ça c'est leeeeent leeeeeeeeeeeeent. Du coup, si je pouvais laisser ce VPN activé en permanence dans un coin, ça m'arrangerait bien.

Avant d'en arriver là, sauf si ton VPN est un VPN privé, la solution d'essayer un autre client VPN public (IpSec, comme l'a dit Drs) s'impose.

JE ne saurais dire si c'est un VPN privé. S'agissant d'un VPN d'entreprise, je suppose que oui.
Quand bien même, je ne suis pas sûr de savoir comment recomposer une connexion en IPsec. Il faut que je télécharge un truc en particulier ?

Alors, tout de suite, ça m'a paru être une idée géniale, mais vu les tests précédents, on va retomber sur le pb de la route par défaut...
Le pb est lié au routage, et pas à la configuration de l'interface (enfin, je crois)

Il y a peut-être une solution via le routage par interface, avec les deux connexions ethernet établies simultanément.
A creuser...

Bon, il faudra donc que je le tire, ce second câble…
Du coup ça nous reporte plutôt à la semaine prochaine car je n'ai plus d'ethernet 5m dispo sous la main pour le moment.

 

[Polo35230]

Alors oui, si c'est un VPN d'entreprise, c'est un VPN privé.
C'est l'administrateur (côté serveur VPN) qui pourra te le dire, mais ça m'étonnerait qu'il fasse du sur-mesure...

Pour les tests avec le second câble, donc les deux interfaces ethernet, je ne sais pas si ça marchera, mais j'y crois un peu (tout petit peu...)
J'ai simulé les deux interfaces chez moi (eth et wifi). Les deux interfaces étant en DHCP auto.
Résultat: deux adresses IP, et deux routes par défaut vers la box. Normal, mais l'ordre des routes a son importance. La deuxième route créée passe devant l'autre.
Donc pour ton test, quand tu auras le câble, il faudra créer ta deuxième interface en dhcp auto et vérifier qu'elle a bien récupéré une adresse IP, un masque, un routeur, des DNS.
Faire ensuite un ifconfig pour repérer les noms de tes interfaces ethernet (par exemple en0 et en1) et vérifier qu'elle sont bien actives.

Ensuite, il faudra
Désactiver la nouvelle interface.
Lancer ton VPN. l'interface jnc0 sera raccrochée à l'interface active, soit en0
Un netstat -r montrera qu'il a créé une route par défaut qui sera positionnée en 1ère position
Faire les "route add" des sites vers jnc0 (donc elles passeront par en0).
Activer la nouvelle interface ethernet (en1?), et fair un netstat -r
En principe, il devrait y avoir 3 routes par défaut.
La première sur la nouvelle interface eth (en1)
La deuxième sur le VPN (jnc0)
La troisième sur en0.

Après, faudrait croiser les doigts, en espérant que la route par défaut opérationnelle soit la première, les sites concernés par les "route add" passant par le VPN...
Bon, on peut réver...
Et si ça ne marche pas, tu pourras tjs te dire que "l'effort est d'autant plus beau qu'il est inutile..."

 

[ccciolll]

Oui, de toutes façons j'essaierai tout ce que je peux, du moins en interne.
Parce que du sur-mesure, vu que le VPN est celui d'un groupe Européen dont le siège est basé dans un pays non francophone, ce n'est même pas la peine d'y penser.

Braaaziiiiiiil… lala lala lala lalaaaaaaa

 

[Polo35230]

Si c'est une connexion à partir de chez toi, tu n'échapperas pas en effet à la bidouille...

Par contre, si tu n'es pas un particulier, et que tu es dans une structure où plusieurs personnes sont amenées à se connecter au VPN de cette société, il y a la possibilité d'installer un équipement (routeur, firewall) qui intègre la fonctionnalité de "Gateway VPN".
Dans ce cas, il n'y a plus de client à installer sur les machines.
C'est une connexion VPN dite de "site à site" ou "gateway to gateway"
C'est la gateway qui se chargera d'établir, et de maintenir le tunnel VPN.
Il faudra biensûr contacter (en portugais...) l'admin du site distant pour le choix de cette passerelle.

 

[ccciolll]

Bonjour,

donc ça y est, j'ai pu tirer mon 2eme câble.

Le ifconfig montre bien 2 accès en0 et en1, actifs tous les deux. Les adresses IP m'indiquent bien que le en0 correspond à la prise 1 et le en1 à la prise 2 (mais c'est peut-être juste déterminé par l'ordre dans lequel j'ai branché les prises, et peut-être la prise 2 deviendrait une en0 si je la branchais en premier).

J'ai tenté la manœuvre que tu avais décrite, mais pour l'instant sans succès.
Je précise que quand je « rend le service inactif » de l'Ethernet 2 (en1), je clique bien ensuite sur « Appliquer » en bas à droite de la fenêtre Réseau (je le précise car la première fois je ne l'avais pas fait, et il faut aussi cliquer sur « appliquer » quand on rend le service actif, évidemment).
Comme tu ne le précises pas, j'ai essayé avec et sans faire de delete route sur le jnc0 avant de faire les add route
Sans le delete route, après avoir relancé en1, j'ai jnc0 qui se met en premier de liste, à mon avis c'est pas bon, puis en0 en 2eme, et en1 seulement en 3e.
Et si je fais le delete route, puis relance l'en1, au netstat j'ai toujours en0 qui reste en premier et en1 en deuxième, et plus d'accès internet.

Peut-être que en0 passe devant en1 par défaut et que je devrais tester dans l'autre sens.
Je vois aussi que, via DHCP, il lui faut un certain temps avant de retrouver son IP quand je réactive en1. Peut-être devrais-je mettre en saisie manuelle ?

Enfin, j'ai cru constater, un moment donné quand j'avais testé avec un delete route de jnc0 et après avoir réactivé en1, que jnc0 s'était réactivé tout seul après une tentative d'accès internet. C'est possible ça ou c'est moi qui ai fait une mauvaise manip ?

---------- Nouveau message ajouté à 12h44 ---------- Le message précédent a été envoyé à 12h24 ----------

J'ai testé dans l'autre sens (en désactivant en0).

J'ai fait les manœuvres
désactiver en0 et appliquer
démarrer le VPN
un netstat pour vérifier le tunnel du vpn
delete tunnel (route) du vpn
add route vers le serveur
un nestat en passant montre en1 en premier, jnc0 en deuxième (vers le serveur), puis lo0 en 3e vers le tunnel (je ne sais pas ce que c'est), etc.
réactivation de en0 et appliquer.
Puis re netstat.
Là j'ai bien en0 en 1er, en1 en 2e, jnco vers serveur en 3e.

Mais pas d'accès internet.

Bon, je réessayerai avec le ventre plein, car là je sens que je perds ma concentration.

---------- Nouveau message ajouté à 13h42 ---------- Le message précédent a été envoyé à 12h44 ----------

Allez, encore un coup 10 minutes d'écriture de résumé perdues…

Je HAIS le VPN.

Alors, on refait le boulot…

Donc je disais, je viens de refaire le test (en dés/activant plutôt en0 que en1) et j'ai aussi fait 3 fenêtres de surveillance que tu m'avais apprises sudo tcpdump -c 5 -i (en0/en1/jnc0) host 8.8.8.8

Les fenêtres réagissent bien aux pings dans les situations attendues (la en0 quand les 2 sont activé, la en1 quand je désactive la en0, la jnc0 quand j'ai lancé le VPN (bizarre, elle ne sp'appelle pas jnc1 quand elle passe par en1)

mais une fois toute la procédure faite, j'ai bien dans l'ordre sur le netstat en0, en1, jnc0 :

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGScI           0        0     en0
default            192.168.1.1        UGScI           3        0     en1
(ServeurdeFichiers)/32    6a.6e.63.30.0.0.e. UGSc            0        0    jnc0
10.24.251.147      localhost          UGHS            0        0     lo0
10.24.251.147/32   jnc0               UCS             0        0    jnc0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              1        4     lo0
169.254            link#4             UCS             0        0     en0
192.168.1          link#4             UCS             1        0     en0
192.168.1          link#5             UCSI            0        0     en1
192.168.1.1        40:5a:9b:7b:76:1c  UHLS            5        6     en1
192.168.1.10       localhost          UHS             0        1     lo0
192.168.1.12       localhost          UHS             0        1     lo0
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en0
vpn.xxxxxx.com       192.168.1.1        UGHS            2       87     en1

Internet6:
Destination        Gateway            Flags         Netif Expire
localhost          localhost          UH              lo0
fe80::%lo0         localhost          Uc              lo0
localhost          link#1             UHL             lo0
fe80::%en0         link#4             UC              en0
mac-pro-de-xx-xx 0:17:f2:e:e9:a     UHL             lo0
fe80::%en1         link#5             UC              en1
mac-pro-de-xx-xx 0:17:f2:e:e9:b     UHL             lo0
ff01::             localhost          Um              lo0
ff02::             localhost          UmC             lo0

mais le ping ne donne rien :

PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
ping: sendto: No route to host
Request timeout for icmp_seq 3

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Grlmblbmmm…

Donc à priori pas de solution sans un 2e ordi (ou des dé/connexions incessantes avec cette béquille branlante qu'est le VPN).

Ce xxxxx de Network Connect ne laisse plus rien sortir dès qu'il est activé.

 

[Polo35230]

Le ifconfig montre bien 2 accès en0 et en1, actifs tous les deux. Les adresses IP m'indiquent bien que le en0 correspond à la prise 1 et le en1 à la prise 2 (mais c'est peut-être juste déterminé par l'ordre dans lequel j'ai branché les prises, et peut-être la prise 2 deviendrait une en0 si je la branchais en premier).

Non, ce n'est pas une question d'ordre? C'est lié au port physique.

Comme tu ne le précises pas, j'ai essayé avec et sans faire de delete route sur le jnc0 avant de faire les add route

Il ne faut plus faire de delete route.

Sans le delete route, après avoir relancé en1, j'ai jnc0 qui se met en premier de liste, à mon avis c'est pas bon, puis en0 en 2eme, et en1 seulement en 3e.

Oui, c'est pas bon...

Je regarde la suite de ton message...