Merci David !! Tu vas pouvoir passer une bonne soirée ta solution fonctionne :)
Bravo et encore merci !
De : David Ponzone <[email protected]>
À : Antoine Durant <[email protected]>
Cc : Frnog-tech <[email protected]>
Envoyé le : Mercredi 24 juin 2015 20h23
Objet : Re: [FRnOG] [TECH] problème de route pour un ping !
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/
