Why I can ping Hosts behind NAT router????

[pmesjar]

I set up myself this simple lab scenario:

Two routers back to back - serial 0 on router RTA to serial 1 on router RTB. I have connected one Catalyst 1900 switch to RTA, second to RTB, each to respective Ethernet interface on router. There is no dynamic routing protocol, only static routes.
IP addressing:
RTA S0: 1.0.0.2/8
E0: 192.100.40.1/24
RTB S1: 1.0.0.1/8
E0: 192.100.30.1/24
Without NAT enabled everybody can talk to everybody. Host to hosts, routers to routers, etc...

Now, I have configured NAT on RTA with following commands:
E0: ip nat inside
S0: ip nat outside
ip nat inside source static tcp 192.100.40.6 80 1.0.0.2 80
access-list 1 permit 192.100.40.0 0.0.0.255
ip nat inside source list 1 interface s0 overload
Suppose the NAT translation table is empty, containing only static translation. For laboratory purposes and to better understand NAT, when pinging I am using IP addresses that are configured on LAN hosts.

The problem is - when I ping "nated" hosts behind RTA directly from RTB or from hosts behind RTB, using their configured "real" IP addresses, I get replies. WHY??? According to my knowledge of NAT order of operation, when communicating from outside to inside:
FIRST : NAT translation table is checked if it contains translation entry for given destination address and port, if it is not here, packets will be dropped
SECOND: Routing table is checked to deliver translated packet to destination, if there is no route, packets will be dropped
Form inside to outside steps are otherwise.

Then why I am able to ping them? Is it because I directly know the real IP address of nated hosts? But then I must conclude, that FIRST step I described above won't be applied in case of real IP addresses traveling through NAT router, and packets will be directly routed to destination and NAT will fail. If this is the case, I would really appreciate if anybody can clear this "NAT behaviour" to me or point to some useful links where they explain similar cases.

Second problem. Now, while RTA is configured with NAT, I have configured same NAT scenario on RTB - same commands, but of course IP addresses must match my subnets. Now when I am pinging hosts behind RTA from hosts behind RTB and vice-versa I don't get any replies. That is what I want to achieve. BUT! When I ping directly from router RTA hosts behind RTB and hosts behind RTB directly from RTA, I do get replies!!!

I am getting confused about this NAT operation. I know that NAT should be hiding IP addresses from outside "evil" world, but once somebody learns my real IP he can connect to me. From outputs of debug ip nat detailed I could not dig something useful. Do I have to apply additional access-list rules to filter also IP addresses comming to my NAT router, that will deny packets with destination IP address of my private hosts? But this defy the NAT order of operation as it is described on Cisco's webpages.

If anybody could just please clear this matter to me, I would greatly appreciate it. Or tell if I am totally wrong and this can never happen... I am sure I am missing the last small step in my full understanding of NAT

Tahnk you all in advance

Note: Static translation was working in both cases. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[l1carter]

Peter,

Since this is in a Lab situation, can you post your full router configs for RTA and RTB? Also, can you post your routing tables for RTA and RTB?

thanks,

Lee

 

[pmesjar]

They will be here tomorrow Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[pmesjar]

Here are the configurations, pretty simple. I have changed just IP addresses:

============ ROUTERA ======================================

version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname RouterA
!
!
ip subnet-zero
!
!
!
!
interface Ethernet0
ip address 192.100.30.1 255.255.255.0
no ip directed-broadcast
ip nat inside
!
interface Ethernet1
no ip address
no ip directed-broadcast
shutdown
!
interface Serial0
ip address 1.0.0.1 255.0.0.0
no ip directed-broadcast
shutdown
clockrate 250000
!
interface Serial1
ip address 1.0.0.1 255.0.0.0
no ip directed-broadcast
ip nat outside
!
ip nat inside source list 1 interface Serial1 overload
no ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 1.0.0.2
!
access-list 1 permit 192.100.30.0 0.0.0.255
!
line con 0
transport input none
line aux 0
line vty 0 4
login
!
end

The routing table of our NAT enabled RouterA:
RouterA#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M -mobile, B - BGP, D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2, E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP, i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default, U - per-user static route, o - ODR, P - periodic downloaded static route, T - traffic engineered route

Gateway of last resort is 1.0.0.2 to network 0.0.0.0

C 1.0.0.0/8 is directly connected, Serial1
C 192.100.30.0/24 is directly connected, Ethernet0
S* 0.0.0.0/0 [1/0] via 1.0.0.2


============ ROUTERB ======================================

version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname RouterB
!
!
ip subnet-zero
!
!
!
!
interface Ethernet0
ip address 192.100.40.1 255.255.255.0
no ip directed-broadcast
!
interface Serial0
ip address 1.0.0.2 255.0.0.0
no ip directed-broadcast
no ip mroute-cache
clockrate 250000
!
interface Serial1
ip address 1.0.0.2 255.0.0.0
no ip directed-broadcast
shutdown
!
no ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 1.0.0.1
!
!
line con 0
transport input none
line aux 0
line vty 0 4
login
!
end

The routing table of our NAT enabled RouterA:
RouterB#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP, D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2, E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP, i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default, U - per-user static route, o - ODR, P - periodic downloaded static route, T - traffic engineered route

Gateway of last resort is 1.0.0.1 to network 0.0.0.0

C 1.0.0.0/8 is directly connected, Serial0
C 192.100.40.0/24 is directly connected, Ethernet0
S* 0.0.0.0/0 [1/0] via 1.0.0.1


Hope anybody will know the right answer)) Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[pmesjar]

One more thing I have noticed. With NAT enabled as I have posted, pings can pass from one host to another, but if I want to connect to Web server on host behind NAT with its real IP address, it fails. After I remove NAT, everything works just fine. So now I am assuming, that it works like it should except for pinging hosts behind NAT with their real IP addresses. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[sharkyj72]

This is difficult to troubleshoot since your post configs do not match your original question (you had a static mapping for

http://www which

doesnt seem to exist now).

However I thing you are getting confused on how NAT works. You need to step through your tests and plot how nat is behaving. Use the debug ip packet and debug ip nat commands to see what is happening.

remember also that pinging from a router console often is not the same (source address wise) as pinging from a host on a network attached to the router.

If you want to simulate pinging from the ethernet subnet, use an extended ping command.

 

[pmesjar]

Whether the static mapping is ther or not, it works like I have described, so if you want to, just add the configuration commands there:

ip nat inside source static tcp 192.100.30.4 80 1.0.0.1 80

I am getting confused, because I am able to ping in cases where I shouldn't, but when trying to establish

http://WWW connection,

it won't let me, which is how it should work.

With ping and extended ping - I have to say I do not agree with you because my point was:
If I am pinging from host on 192.100.40.0/24 subnet to host on subnet 192.100.30.0/24, that is to be NATed, with its configured IP address from this range, it will let me. And that is if I want to ping from host or from router - it does not matter. But if I want to establish

http://WWW connection,

it will not let me (what is good, because I am not allowing him without any static entry).

I have also watched the results of debug ip nat command and it behaved like this:
Incoming pings were passed without any modifications, but echo replies were NATed and then sent to originating source. From debug ip packt I could not dig anything useful.

For now, thanx for your reply Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[l1carter]

Peter,

I will test this in my lab as well. but I think everything is working correctly. You "normaly" would not be able to ping hosts behing a NAT address unless it was forwarded but this is because the internet will not allow those private addresses to route across the NET. so your packets destined to a 192.168.30.x address would simply be droped by your provider.

Not knowing for sure... I'll try to explain what I think is happening...


Extended ping from host 192.168.40.1 to host 192.168.30.1

If you did a debug icmp on RouterB just before you kicked off the ping you will more than likely see the source echo reply from RouterA's Serial inteface (1.0.0.1)

When you send a ping to 192.168.30.1 from RouterB, the router does not have a route for it. So it will take the default route...(RouterA). Then rotuer has it and it looks at the packet and it's local routing table. It does have a connected route for 192.168.30.x and so it hands it off to the ethernet interface for processing.

Now that interface looks at the destination address and sees that it's set to go to it's ethernet face. If that interface is up/up you get a echo reply generated with source address of 192.168.30.1 and dest address of 192.168.40.1.

Again, RotuerA now looks in its routing table for a route to 192.168.40.x and has none so it too goes to the default gateway. Only this time there are access lists and Nat statements that must be processed before shipping the packet off. That is done and away it goes with a new source address of 1.0.0.1 and a dest address of 192.168.30.1.

If the following command is in the router..

ip nat inside source static tcp 192.100.30.4 80 1.0.0.1 80


then from a host on RouterB's Ethernet LAN Segment can you not go to

http://1.0.0.1

and see the web server on 192.100.30.4 ???

If you try what does the debug ip nat show when this is trying to happen. (I assume that the 192.100.30.4 host is alive and has a valid web server bound to port 80).

 

[pmesjar]

You want to try it in your lab? That's great. Could you please then post me your router configurations, so we can see differences, if there will be any (except IP addresses of course)

I must react to the statement you are explaining how routers route this address:

> When you send a ping to 192.168.30.1 from RouterB, the router does not have a route for it. So it will take the default route...(RouterA). Then rotuer has it and it looks at the packet and it's local routing table. It does have a connected route for 192.168.30.x and so it hands it off to the ethernet interface for processing.
> Now that interface looks at the destination address and sees that it's set to go to it's ethernet face. If that interface is up/up you get a echo reply generated with source address of 192.168.30.1 and dest address of 192.168.40.1.

One remark - if NAT is configured on RouterA, he should not route packets to NATed destination before he looks into his NAT table. And since his NAT table is empty, he is supposed to discard the packet not route it to his connected interface, even if it is in his routing table. Well, it is doing NAT the right way for port 80 traffic, but with pings, NAT part of process is skipped and router looks directly into its routing table. But when sending echo-replies back, they are NATed and then sent back.

Your question about static NAT translation. That works, so no problem here. And please, forget that IP addresses are from private range. I know they are discarded by ISP's but if this problem is with private address, it can be applied to any address. Private addresses are normally routable, but are denied and not forwarded by any router of any ISP.

Thanx for reply so far. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[sharkyj72]

Peter,

I have 2 theories...

Theory 1.

I think the difference between the behaviour of your pings and a tcp web connection is down to the 'origin' of the traffic.

When you ping from the outside, the icmp echo originates from the outside (obviously). It hits the inside router, does not get translated (no entry in nat table) and routed to the destination.

The destination then sends back an echo-reply which 'originates' from itself. The inside router has a rule that translates the source address of the echo-reply (1 entry in nat table) and then it is sent on its way to the outside host.

When you try to establish a port 80 connection via tcp you step into the tcp 3 way handshake scenario (syn, ack, syn ack). The tcp request on port 80 originates from the outside. It hits the inside router, does not get translated and I believe is dropped. Reason? NAT knows that port 80 requires tcp 3 way handshake conversation, and that the conversation (in this case) is always going to originate from the outside. It does not have a mapping for outside - inside translations so it drops the packet.

ICMP pings on the other hand can generate traffic that originates from both the outside and inside. And its one way.

Theory 2.

According to Cisco, using IP NAT INSIDE generates the following behaviour,

inside traffic -> translation occurs on source address
outside traffic -> translation occurs on destination address.

So a ping from 192.100.40.1 to 192.100.30.1 would get routed to 1.0.0.1 (destination changes from 192.100.30.1 to 1.0.0.1. 1.0.0.1 then echo replies to 192.100.40.1 which equals success (1.0.0.1 knows about icmp).

A tcp port 80 request from 192.100.40.1 to 192.100.30.1 would get routed to 1.0.0.1. 1.0.0.1 doesnt know anything about port 80 services so drops the packet. Result equals failure to connect on port 80.

To test these theories I would install ethereal (free packet sniffer) on the hosts at each end to see what traffic is sent/received under ping and tcp port 80 connection attempts. Also as I mentioned before I would setup debug ip packet detail and debug ip nat to capture the router operations.

 

[pmesjar]

You are writing:
> So a ping from 192.100.40.1 to 192.100.30.1 would get routed to 1.0.0.1 (destination changes from 192.100.30.1 to 1.0.0.1. 1.0.0.1 then echo replies to 192.100.40.1 which equals success (1.0.0.1 knows about icmp).

But why is it routed, when it should be first looked up in NAT table? However, NAT router does not have any entry in NAT table. He is supposed to discard the packet, does not matter if it is ICMP, TCP, UDP ar whatever traffic will traverse NAT router.
I am just standing to the NAT order of operation, which can be find here:

http://www.cisco.com/warp/public/556/5.html

And if there is nothing wrong with my "problem", isn't it true, that once an attacker finds out my real IP address (finding out IP addresses that should be hidden is like finding out passwords that should be also hidden), he can launch some sort of DoS attack using ICMP protocol?
Unless I block any incoming packets (except those statically NATed) at my firewall that use real, configured IP address (inside local) in their destination field. I do not have any practical experience configuring firewalls, but sounds to me like logical way how some of rules are really configured in firewalls.

The idea with Ethereal is great, I hope I will be able to try it tomorrow. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[sharkyj72]

Peter,

Regardless of whether it should be dropped or routed I cannot see how this would be a problem in the 'real world'.

If you were NAT'ing to the internet, you private address range would be unknown or filtered by your ISP and thus not advertised to the rest of the world.

If you were NAT'ing to another private LAN via a WAN link, would you advertise your local subnet to the remote network ? Probably not. You certainly would'nt have d/f gateways pointing at each other.

Try setting this up with a more realistic scenario. Instead of using d/f gateways, setup a static route back to the global range (10.0.0.1) and see if you pings to 192.100.30.1 still work.

 

[pmesjar]

SHARKYJ72
Hey, I think that private range is:
192.168.0.0/16
not
192.100.0.0/16 <- my inside addresses

and

10.0.0.0/8
not
1.0.0.0/8 <- my outside addresses
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Haven't you read my last post?

And if there is nothing wrong with my &quot;problem&quot;, isn't it true, that once an attacker finds out my real IP address (finding out IP addresses that should be hidden is like finding out passwords that should be also hidden), he can launch some sort of DoS attack using ICMP protocol?

And that is regardless whether I have private addresses (I know those will be blocked) or publicly available and Internet routable addresses (in which cas I will be doing overlapping NAT). Once he finds out, he is in through pings and can do a bunch of damage to my network.

And with that filtering thing about ISP - that means that Cisco did not implement NAT properly. Becasuse together with NAT I must add some sort of ACL that will block incoming packets having destination address same as my really configured. And I don't think it is the right way how to do NAT. And in any NAT example on their web pages there is nothing mentioned about setting up additional ACL.

> Try setting this up with a more realistic scenario. Instead of using d/f gateways, setup a static route back to the global range (10.0.0.1) and see if you pings to 192.100.30.1 still work.

It was also tried with more routers between these two and the effect was the same. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[pmesjar]

I must correct myself about last statement I made:

> Try setting this up with a more realistic scenario. Instead of using d/f gateways, setup a static route back to the global range (10.0.0.1) and see if you pings to 192.100.30.1 still work.

It was also tried with more routers between these two and the effect was the same.

But the router between had static IP routes configured, so these packets could get to the destination behidn NAT. My problem does not seem to work with dynamic routing protocols with passive-interface command used. So the problem surely lies in configured static default gateway routes.

And if I think about my &quot;problem&quot; in really real way, I don't think either that my &quot;problematic&quot; pings will reach destination because only my local router would know about destination.

But still this NAT behaviour is little strange to me in two routers back-to-back configuration.

Thank you guys all for answers. Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[l1carter]

The Connections look something like this (Please excuse my ASCII art):

<---S0/0(R-Wisconson)3/0<<-(.1)-192.168.69.x/24-(.2)->>S0(R-Vermont)S1<-(.1)-1.1.1.0/30-(.2)->S1(R-Kansas)E0---->


R-Wisconson uses source IP of 192.168.69.1 and is acting like a host that will have it's source address nat'ed.
look at the configurations below and see how I can munipulate the routing table to get the exact same results as you did.
I believe that this is a correct operation for NAT.







sh run
Building configuration...

Current configuration : 1948 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname R-WISCONSIN
!
logging console warnings
!
ip subnet-zero
!
no ip domain-lookup
!
interface Serial3/0
description Connection to NAT router
ip address 192.168.69.1 255.255.255.0
clock rate 19200
!
banner motd ^C

R-WISCONSIN

CISCO 3640

^C
!
line con 0
login local
line aux 0
line vty 0 4
login local
end

R-WISCONSIN#sh ip rotue   ute
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

D 172.16.0.0/16 [90/1889792] via 10.0.1.1, 2w4d, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.1.0 is directly connected, Serial0/0
C 192.168.69.0/24 is directly connected, Serial3/0
R-WISCONSIN#sh ip int brief
Interface IP-Address OK? Method Status Prot
ocol
FastEthernet0/0 unassigned YES unset administratively down down

Serial0/0 10.0.1.2 YES manual up up

Serial0/1 unassigned YES unset down down

Serial0/1.100 192.168.100.1 YES manual down down

Serial0/1.200 192.168.100.5 YES manual down down

ATM2/0 unassigned YES unset administratively down down

ATM2/1 unassigned YES unset administratively down down

ATM2/2 unassigned YES unset administratively down down

ATM2/3 unassigned YES unset administratively down down

Serial3/0 192.168.69.1 YES manual up up

Serial3/1 unassigned YES unset administratively down down

Serial3/2 unassigned YES unset administratively down down

Serial3/3 unassigned YES unset administratively down down

R-WISCONSIN#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
......
Success rate is 0 percent (0/5)
R-WISCONSIN#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R-WISCONSIN(config)#ip route 1.1.1.0 255.255.255.252 192.168.69.2
R-WISCONSIN(config)#end
R-WISCONSIN#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/92/92 ms
R-WISCONSIN#sh ip rotue   ute
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
S 1.1.1.0 [1/0] via 192.168.69.2
D 172.16.0.0/16 [90/1889792] via 10.0.1.1, 2w4d, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.1.0 is directly connected, Serial0/0
C 192.168.69.0/24 is directly connected, Serial3/0
R-WISCONSIN#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R-WISCONSIN(config)#no ip route 1.1.1.0 255.255.255.252 192.168.69.2
R-WISCONSIN(config)#end
R-WISCONSIN#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
......
Success rate is 0 percent (0/5)
R-WISCONSIN#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

D 172.16.0.0/16 [90/1889792] via 10.0.1.1, 2w4d, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.1.0 is directly connected, Serial0/0
C 192.168.69.0/24 is directly connected, Serial3/0
R-WISCONSIN#exit




R-WISCONSIN con0 is now available

Press RETURN to get started.


R-VERMONT#sh run
Building configuration...

Current configuration : 991 bytes
!
version 12.1
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname R-VERMONT
!
logging console warnings
!
!
ip subnet-zero
no ip domain-lookup
!
partition flash 2 8 8
!
!
interface Serial0
description Inside NAT Conenction
ip address 192.168.69.2 255.255.255.0
ip nat inside
no fair-queue
!
interface Serial1
description Outside TEST NAT
ip address 1.1.1.1 255.255.255.252
ip nat outside
!
ip nat inside source list 1 interface Serial1 overload
!
access-list 1 permit 192.168.0.0 0.0.255.255
access-list 1 remark VLAID HOST ID's To NAT
!
banner motd ^C

R-VERMONT

CISCO 2502

^C
!
line con 0
login local
line aux 0
line vty 0 4
login local
end

R-VERMONT#sh ip nat tr
R-VERMONT#sh ip nat translations



R-VERMONT#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial1
C 192.168.69.0/24 is directly connected, Serial0
R-VERMONT#sh ip int brie
R-VERMONT#sh ip int brief
Interface IP-Address OK? Method Status Prot
ocol
Serial0 192.168.69.2 YES manual up up

Serial0.1 unassigned YES manual deleted down

Serial1 1.1.1.1 YES manual up up

TokenRing0 unassigned YES unset administratively down down

R-VERMONT#ping
Protocol [ip]:
Target IP address: 1.1.1.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: serial0
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
R-VERMONT#sh ip nat tr
Pro Inside global Inside local Outside local Outside global
icmp 1.1.1.1:4955 192.168.69.2:4955 1.1.1.2:4955 1.1.1.2:4955
icmp 1.1.1.1:4956 192.168.69.2:4956 1.1.1.2:4956 1.1.1.2:4956
icmp 1.1.1.1:4957 192.168.69.2:4957 1.1.1.2:4957 1.1.1.2:4957
icmp 1.1.1.1:4958 192.168.69.2:4958 1.1.1.2:4958 1.1.1.2:4958
icmp 1.1.1.1:4959 192.168.69.2:4959 1.1.1.2:4959 1.1.1.2:4959
R-VERMONT#exit

R-VERMONT con0 is now available

Press RETURN to get started.

R-KANSAS#sh run
Building configuration...

Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname R-KANSAS
!
logging console warnings
!
interface Ethernet0
description LAN Connection
ip address 3.3.3.1 255.255.255.0
no ip directed-broadcast
!
interface Serial1
description NAT Test
ip address 1.1.1.2 255.255.255.252
no ip directed-broadcast
clockrate 4000000
!
!
banner motd ^C

R-KANSAS

CISCO 2503
^C
!
line con 0
login local
login
transport input none
line aux 0
line vty 0 4
login local!
end

R-KANSAS#  sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Ethernet0
R-KANSAS#sh ip int brief
Interface IP-Address OK? Method Status Protocol
BRI0 unassigned YES unset administratively down down
BRI0:1 unassigned YES unset administratively down down
BRI0:2 unassigned YES unset administratively down down
Ethernet0 3.3.3.1 YES manual up up
Serial0 unassigned YES manual administratively down down
Serial0.1 unassigned YES manual deleted down
Serial1 1.1.1.2 YES manual up up
R-KANSAS#sh ver
Cisco Internetwork Operating System Software
IOS (tm) 2500 Software (C2500-I-L), Version 12.0(8), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Mon 29-Nov-99 13:23 by kpma
Image text-base: 0x0302F208, data-base: 0x00001000

ROM: System Bootstrap, Version 11.0(10c), SOFTWARE
BOOTFLASH: 3000 Bootstrap Software (IGS-BOOT-R), Version 11.0(10c), RELEASE SOFT
WARE (fc1)

R-KANSAS uptime is 3 weeks, 3 days, 6 hours, 8 minutes
System restarted by power-on
System image file is &quot;flash:c2500-i-l.120-8.bin&quot;

cisco 2500 (68030) processor (revision N) with 2048K/2048K bytes of memory.
Processor board ID 06058412, with hardware revision 00000001
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 Ethernet/IEEE 802.3 interface(s)
2 Serial network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read ONLY)

Configuration register is 0x2102

R-KANSAS#