Ah ok, je comprends mieux.

Donc c’est bien un ip nat inside qu’il faut mais tu veux pas NATer vers 
192.168.1.0/24 pour que la réponse au ping fonctionne:

ip nat inside source list 100 interface Loopback0 overload
access-list 100 deny ip 10.0.1.0 0.0.0.3 192.168.1.0 0.0.0.255
access-list 100 permit ip 10.0.1.0 0.0.0.3 any

Allez, dis-moi que ça marche, que je passe une bonne soirée, et qu’on passe à 
autre chose :)

Le 24 juin 2015 à 19:54, Antoine Durant <[email protected]> a écrit :

> Salut David !
>  
> > ip nat inside source list 100 interface Loopback0 overload
> > access-list 100 permit ip 10.0.1.0 0.0.0.3 any
> 
> >>Là, par contre, j’ai un problème.
> >>Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside 
> >>» FE4 et qui vont vers « ip nat inside » >>VLAN1, l’inverse donc, la règle 
> >>doit être:
> >>ip nat outside source list 100 interface Loopback0 overload
> >>et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP 
> >>de FE4, ou l’interface de RTR_A qui >>porte 10.0.1.2.
> >>J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal 
> >>placée ne serait pas la cause de ton >>problème.
>  
> Oui comme tu le précise mon problème est sur l'ACL n°100 (je n'ai pas de 
> problème avec la 101)
>  
> J'ai placé volontairement cette ACL pour pouvoir depuis le RTR pinguer des 
> adresses extérieures en sortant avec l'IP de la loopback0
>  
> Celle ci me pose problème car le ping sur les intercos ne fonctionne pas.
> Si j'enlève l'ACL 100 je peux pinguer mes IPs d'interco mais pas une IP dans 
> le "WAN"
>  
> De : David Ponzone <[email protected]>
> À : Antoine Durant <[email protected]> 
> Cc : Frnog-tech <[email protected]> 
> Envoyé le : Mercredi 24 juin 2015 1h06
> Objet : Re: [FRnOG] [TECH] problème de route pour un ping !
> 
> Voilà déjà un truc qui me plait pas:
> 
> > interface FastEthernet4
> >  ip address 10.0.1.1 255.255.255.252
> >  no ip redirects
> >  no ip unreachables
> >  no ip proxy-arp
> >  ip nat outside
> >  ip virtual-reassembly in
> >  ip verify unicast reverse-path
> >  duplex full
> >  speed 100
> > !
> > interface Vlan1
> >  ip address 172.16.1.254 255.255.255.0
> >  no ip redirects
> >  no ip unreachables
> >  no ip proxy-arp
> >  ip nat inside
> >  ip virtual-reassembly in
> >  ip verify unicast reverse-path
> 
> > ip nat inside source list 101 interface Loopback0 overload
> > access-list 101 permit ip 172.16.1.0 0.0.0.255 any
> > !
> 
> Ca, c’est ok. Les paquets arrivant par VLAN1 avec 172.16.1.0/24 comme IP 
> source et qui ressortent par FE4 (la default) vont être NATés en 
> 192.168.1.100.
> 
> > ip nat inside source list 100 interface Loopback0 overload
> > access-list 100 permit ip 10.0.1.0 0.0.0.3 any
> 
> Là, par contre, j’ai un problème.
> Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » 
> FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit 
> être:
> ip nat outside source list 100 interface Loopback0 overload
> et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP 
> de FE4, ou l’interface de RTR_A qui porte 10.0.1.2.
> J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal 
> placée ne serait pas la cause de ton problème.
> 
> 
> 
> 
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à