Prev: PIX 515E remote access vpn with DHCP pushed to the client
Next: automating username/password when ssh to cisco router
From: Laurent on 15 Apr 2008 10:47
News Reader a �crit :
> Are there any ACLs on L0 or E0 that are not shown in the output below?
no. only these..
this is the new config (without routing after nat)

---- begin ----
!
interface Loopback0
ip address 10.200.210.240 255.255.255.0
ip nat outside
!
interface Ethernet0
ip address 192.168.254.4 255.255.255.0
ip nat inside
ip policy route-map NatSource
!
ip nat inside source list 101 interface Loopback0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.254.6
!
logging trap debugging
logging facility local0
logging 192.168.254.7
access-list 101 permit ip 192.168.254.0 0.0.0.255 172.20.2.0 0.0.0.255
access-list 110 permit ip 10.200.210.0 0.0.0.255 172.20.2.0 0.0.0.255
route-map NatSource permit 10
match ip address 101
set ip next-hop 10.200.210.1
!
---- end ----

don't work better, as i said.. :(

I leaved the acl 110 :
it's no more used, it should not be a problem..
From: News Reader on 15 Apr 2008 11:46
Laurent wrote:
> News Reader a �crit :
>> Are there any ACLs on L0 or E0 that are not shown in the output below?
> no. only these..
> this is the new config (without routing after nat)
>
> ---- begin ----
> !
> interface Loopback0
> ip address 10.200.210.240 255.255.255.0
> ip nat outside
> !
> interface Ethernet0
> ip address 192.168.254.4 255.255.255.0
> ip nat inside
> ip policy route-map NatSource
> !
> ip nat inside source list 101 interface Loopback0 overload
> ip classless
> ip route 0.0.0.0 0.0.0.0 192.168.254.6
> !
> logging trap debugging
> logging facility local0
> logging 192.168.254.7
> access-list 101 permit ip 192.168.254.0 0.0.0.255 172.20.2.0 0.0.0.255
> access-list 110 permit ip 10.200.210.0 0.0.0.255 172.20.2.0 0.0.0.255
> route-map NatSource permit 10
> match ip address 101
> set ip next-hop 10.200.210.1
> !
> ---- end ----
>
> don't work better, as i said.. :(
>
> I leaved the acl 110 :
> it's no more used, it should not be a problem..

The pinging host (192.168.254.110) is using E0 (192.168.254.4) as its
default gateway, right?

Can I assume there is no other NAT being performed (e.g.: on 172.20.2.0)?

Have you examined the NAT translations (sh ip nat translations) to
confirm that they are what you expect?

Have you placed a sniffer on the network to verify the IP addresses
within the packets on both the outbound and return paths? Seeing is
believing.

Best Regards,
News Reader
From: Laurent on 16 Apr 2008 04:40
News Reader a �crit :
> The pinging host (192.168.254.110) is using E0 (192.168.254.4) as its
> default gateway, right?
Not the default gateway, there's a route for this destination (172.20.2).

> Can I assume there is no other NAT being performed (e.g.: on 172.20.2.0)?
no other nat. :)

> Have you examined the NAT translations (sh ip nat translations) to
> confirm that they are what you expect?
Yes, it seems to be ok :
Pro Inside global Inside local Outside local
Outside global
icmp 10.200.210.240:1280 192.168.254.110:1280 172.20.2.75:1280
172.20.2.75:1280

> Have you placed a sniffer on the network to verify the IP addresses
> within the packets on both the outbound and return paths? Seeing is
> believing.
result for just one ping :
10:34:52.609141 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
seq 31750
10:34:52.609202 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
seq 31750
10:34:52.616734 IP 10.200.210.240 > 172.20.2.75: icmp 40: echo request
seq 31750
10:34:52.672776 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
31750
10:34:52.672879 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
31750

nothing else..


thank you for your interest :)
From: Bod43 on 16 Apr 2008 08:39
On 16 Apr, 10:40, Laurent <lpo...(a)alussinan.org> wrote:
> News Reader a écrit :> The pinging host (192.168.254.110) is using E0 (192.168.254.4) as its
> > default gateway, right?
>
> Not the default gateway, there's a route for this destination (172.20.2).
>
> > Can I assume there is no other NAT being performed (e.g.: on 172.20.2.0)?
>
> no other nat. :)
>
> > Have you examined the NAT translations (sh ip nat translations) to
> > confirm that they are what you expect?
>
> Yes, it seems to be ok :
> Pro Inside global         Inside local          Outside local
> Outside global
> icmp 10.200.210.240:1280  192.168.254.110:1280  172.20.2.75:1280
> 172.20.2.75:1280
>
> > Have you placed a sniffer on the network to verify the IP addresses
> > within the packets on both the outbound and return paths? Seeing is
> > believing.
>
> result for just one ping :
> 10:34:52.609141 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.609202 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.616734 IP 10.200.210.240 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.672776 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
> 31750
> 10:34:52.672879 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
> 31750
>
> nothing else..
>
> thank you for your interest :)

debug nat

or is it debug ip nat

shows all of the packets. Quite handy.
From: News Reader on 16 Apr 2008 12:07
Laurent wrote:
> News Reader a �crit :
>> The pinging host (192.168.254.110) is using E0 (192.168.254.4) as its
>> default gateway, right?
> Not the default gateway, there's a route for this destination (172.20.2).

Think you mis-understood my question.

When the host (192.168.254.110) is sending a ping to a destination
(172.20.2.75) for which it does not have a route, it uses "it's" default
gateway. I was wanting to confirm that the host's default gateway was
configured as 192.168.254.4, to ensure that packets were using the
router on which your NAT and route-map were configured.

Your NAT translation output below answers the question.

>
>> Can I assume there is no other NAT being performed (e.g.: on 172.20.2.0)?
> no other nat. :)
>
>> Have you examined the NAT translations (sh ip nat translations) to
>> confirm that they are what you expect?
> Yes, it seems to be ok :
> Pro Inside global Inside local Outside local Outside
> global
> icmp 10.200.210.240:1280 192.168.254.110:1280 172.20.2.75:1280
> 172.20.2.75:1280
>
>> Have you placed a sniffer on the network to verify the IP addresses
>> within the packets on both the outbound and return paths? Seeing is
>> believing.
> result for just one ping :

Just one ping? Where is this trace taken from?

Why are you seeing multiple requests/replies with the "same IP addresses
and same seq number"?

Would expect each request to a have a unique seq number; at least from a
Windows host.

Might want to examine the MAC addresses of each packet.

> 10:34:52.609141 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.609202 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.616734 IP 10.200.210.240 > 172.20.2.75: icmp 40: echo request
> seq 31750
> 10:34:52.672776 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
> 31750
> 10:34:52.672879 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq
> 31750
>
> nothing else..
>
>
> thank you for your interest :)

Best Regards,
News Reader
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: PIX 515E remote access vpn with DHCP pushed to the client
Next: automating username/password when ssh to cisco router