[c-nsp] Will NAT-on-a-stick solve this problem?
Bruce Pinsky
bep at whack.org
Tue Oct 26 20:38:12 EDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ed Ravin wrote:
| I am replacing a Netopia DSL router with a Cisco. The existing
| network looks like this:
|
| 192.168.1.0/24 -------- Netopia ----- DSL to Internet
| 10.10.10.9 - router IP address, client NAT
| 10.10.10.10 - public server
|
| Normal use is that clients in 192.168.1.0/24 send packets to the Internet
| that go through NAT and are sourced with the Netopia's address, for
| this example I'll use 10.10.10.9. Server "A" on the 192.168.1.0 network
| needs to be reachable from the Internet, and the Netopia has been told
| to perform NAT for 10.10.10.10 to the server's real IP, 192.168.1.10.
|
| The Netopia has another feature: the NAT for the 10.10.10.10 address
| will work regardless of which side the source packet comes from. If a
| packet from the Internet side comes in for 10.10.10.10, the Netopia
| translates it to 192.168.1.0 and relays it to the LAN side. if a packet
| from the LAN side of the router is destined for 10.10.10.10, it will also
| receive NAT processing and will be routed back to the LAN at 192.168.1.10.
| This is nice and simple for a small office network, even though it's extra
| work for the router.
|
| If I replace the Netopia with a Cisco with the usual NAT configuration,
| everything works fine except that computers on 192.168.1.0/24, when they
| want to reach 10.10.10.10, can't get to the server. I can fix this by
| playing games with DNS so that the customers receive the correct local
| IP address for the server. But for various logistical reasons, it would
| be an easier migration if the Cisco router was willing to do the same
| things the Netopia does.
|
| Will NAT-on-a-stick solve this problem? I'm looking at the Cisco example
| at:
|
|
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml
|
| and it seems like the Cisco can do what I want, but the examples
| given are for a different situation and I'm having trouble using
| them. I want my packets to do something like this:
|
| (inside LAN)
| 192.168.1.5 => 10.10.10.10
|
| (router does one or more NAT translations, routes packet back to inside
LAN)
| 10.10.10.9 => 192.168.1.10
|
| If I understand the NAT-on-a-stick stuff correctly, I should be able to
| use policy routes to send the packets to a loopback interface marked with
| "ip nat outside" in order to get the translation I need?
|
Yes it works. I set it up on a few routers as follows:
host R3 116.16.32.1
|
|
|serial to R3
router R2 with NAT on stick
|eth 116.16.26.2
|
|
|
host R6 116.16.26.6
host R1 116.16.26.4
116.16.26.6 accesses outside world as 10.10.10.9
116.16.26.4 is always static NAT to 10.10.10.10
- -----------
Scenario #1 - R6 pings outside world address 116.16.32.1
R6#ping 116.16.32.1
03:19:13: ICMP: echo reply rcvd, src 116.16.32.1, dst 116.16.26.6
R3 sees as:
R3#
03:19:13: ICMP: echo reply sent, src 116.16.32.1, dst 10.10.10.9
- ---------
Scenario #2 - R3 pings outside world address 10.10.10.10
R3#ping 10.10.10.10
03:21:26: ICMP: echo reply rcvd, src 10.10.10.10, dst 116.16.32.1
R6 sees as:
03:21:26: ICMP: echo reply sent, src 116.16.26.4, dst 116.16.32.1
- ----------
Scenario #3 - R6 pings outside world address 10.10.10.10 which NATs back to
inside address on R1
R6#ping 10.10.10.10
03:26:13: IP: s=116.16.26.6 (local), d=10.10.10.10 (Ethernet0/0), len 100,
sending
03:26:13: ICMP: echo reply rcvd, src 116.16.26.4, dst 116.16.26.6
R1 sees as:
03:26:13: IP: s=116.16.26.6 (Ethernet0/0), d=116.16.26.4 (Ethernet0/0), len
100, rcvd 3
03:26:13: ICMP: echo reply sent, src 116.16.26.4, dst 116.16.26.6
Here the reply to R6 gets sent right back from R1 and doesn't go back to
the NAT'ing router since the addresses are on the same segment.
- -----------------
Scenario #4 - R1 pings outside world address on R3
R1#ping 116.16.32.1
03:45:25: IP: s=116.16.26.4 (local), d=116.16.32.1 (Ethernet0/0), len 100,
sending
03:45:25: IP: s=116.16.32.1 (Ethernet0/0), d=116.16.26.4 (Ethernet0/0), len
100, rcvd 3
03:45:25: ICMP: echo reply rcvd, src 116.16.32.1, dst 116.16.26.4
R3 sees as:
03:42:39: ICMP: echo reply sent, src 116.16.32.1, dst 10.10.10.10
And here is the config:
interface Loopback10
~ ip address 77.77.77.77 255.255.255.0
~ ip nat outside
!
interface Ethernet0/0
~ ip address 116.16.26.2 255.255.255.224
~ ip nat inside
~ ip policy route-map LOOP
!
interface Serial1/0
~ ip address 116.16.32.2 255.255.255.252
~ ip nat outside
~ encapsulation frame-relay
~ frame-relay interface-dlci 202
!
ip nat pool OUTSIDE 10.10.10.9 10.10.10.9 prefix-length 32
ip nat inside source list TO-INTERNET pool OUTSIDE overload
ip nat inside source static 116.16.26.4 10.10.10.10
ip route 10.10.10.10 255.255.255.255 Ethernet0/0
!
!
!
ip access-list extended LOOP-MATCH
~ permit ip 116.16.26.0 0.0.0.255 host 10.10.10.10
ip access-list extended TO-INTERNET
~ deny ip 116.16.26.0 0.0.0.255 host 10.10.10.10
~ permit ip any any
!
!
route-map LOOP permit 10
~ match ip address LOOP-MATCH
~ set interface Loopback10
Debugs on the NAT'ing router
- ------------------------------
Debug output from the policy loop and NAT'ing:
03:37:02: IP: s=116.16.26.6 (Ethernet0/0), d=10.10.10.10, len 100, policy match
03:37:02: IP: route map LOOP, item 10, permit
03:37:02: IP: s=116.16.26.6 (Ethernet0/0), d=10.10.10.10 (Loopback10), len
100, policy routed
03:37:02: IP: Ethernet0/0 to Loopback10 10.10.10.10
03:37:02: IP: s=116.16.26.6 (Ethernet0/0), d=10.10.10.10 (Loopback10),
g=10.10.10.10, len 100, forward
03:37:02: NAT: o: icmp (116.16.26.6, 1104) -> (10.10.10.10, 1104) [295]
03:37:02: NAT: s=116.16.26.6, d=10.10.10.10->116.16.26.4 [295]
03:37:02: IP: s=116.16.26.6 (Loopback10), d=116.16.26.4 (Ethernet0/0),
g=116.16.26.4, len 100, forward
And debug from outside world to 10.10.10.10:
03:39:43: NAT*: o: icmp (116.16.32.1, 6892) -> (10.10.10.10, 6892) [125]
03:39:43: NAT*: s=116.16.32.1, d=10.10.10.10->116.16.26.4 [125]
03:39:43: IP: s=116.16.32.1 (Serial1/0), d=116.16.26.4 (Ethernet0/0),
g=116.16.26.4, len 100, forward
03:39:43: IP: s=116.16.26.4 (Ethernet0/0), d=116.16.32.1 (Serial1/0), len
100, policy rejected -- normal forwarding
03:39:43: NAT: i: icmp (116.16.26.4, 6892) -> (116.16.32.1, 6892) [125]
03:39:43: NAT: s=116.16.26.4->10.10.10.10, d=116.16.32.1 [125]
03:39:43: IP: s=10.10.10.10 (Ethernet0/0), d=116.16.32.1 (Serial1/0),
g=116.16.32.1, len 100, forward
And debug from R1 to outside world:
03:42:38: IP: s=116.16.26.4 (Ethernet0/0), d=116.16.32.1 (Serial1/0), len
100, policy rejected -- normal forwarding
03:42:38: NAT: i: icmp (116.16.26.4, 7261) -> (116.16.32.1, 7261) [300]
03:42:38: NAT: s=116.16.26.4->10.10.10.10, d=116.16.32.1 [300]
03:42:38: IP: s=10.10.10.10 (Ethernet0/0), d=116.16.32.1 (Serial1/0),
g=116.16.32.1, len 100, forward
03:42:39: NAT*: o: icmp (116.16.32.1, 7261) -> (10.10.10.10, 7261) [300]
03:42:39: NAT*: s=116.16.32.1, d=10.10.10.10->116.16.26.4 [300]
03:42:39: IP: s=116.16.32.1 (Serial1/0), d=116.16.26.4 (Ethernet0/0),
g=116.16.26.4, len 100, forward
03:42:39: IP: s=116.16.26.4 (Ethernet0/0), d=116.16.32.1 (Serial1/0), len
100, policy rejected -- normal forwarding
And debug from R6 to the outside world:
03:51:05: IP: s=116.16.26.6 (Ethernet0/0), d=116.16.32.1 (Serial1/0), len
100, policy rejected -- normal forwarding
03:51:05: NAT: Allocated Port for 116.16.26.6 -> 10.10.10.9: wanted 6127
got 6127
03:51:05: NAT: i: icmp (116.16.26.6, 6127) -> (116.16.32.1, 6127) [315]
03:51:05: NAT: s=116.16.26.6->10.10.10.9, d=116.16.32.1 [315]
03:51:05: IP: s=10.10.10.9 (Ethernet0/0), d=116.16.32.1 (Serial1/0),
g=116.16.32.1, len 100, forward
03:51:05: NAT*: o: icmp (116.16.32.1, 6127) -> (10.10.10.9, 6127) [315]
03:51:05: NAT*: s=116.16.32.1, d=10.10.10.9->116.16.26.6 [315]
03:51:05: IP: s=116.16.32.1 (Serial1/0), d=116.16.26.6 (Ethernet0/0),
g=116.16.26.6, len 100, forward
Frankly though, it would be much simpler to run BIND9 and use views to
return the inside address to the clients inside and the global address to
those on the Internet. It's what I do at home :-)
- --
=========
bep
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
iD8DBQFBfu3zE1XcgMgrtyYRApAIAJ9xXcNj0LlKf/zooJyXx6Uac3j18gCgoZzC
FfB68TYncMNvm4jSM/zkFbM=
=dgOQ
-----END PGP SIGNATURE-----
More information about the cisco-nsp
mailing list