[c-nsp] Getting stuck with NAT-on-a-stick
Rodney Dunn
rodunn at cisco.com
Mon Nov 8 16:15:23 EST 2004
----------------------------------------- (on bantam)
Tacsuns has scanned the file natonastick.html and no virus was found.
---------------------------------------------------------
-------------- next part --------------
Ed,
These NAT-on-a-stick configurations are always hard
to follow. Here is how I suggest you do it.
Draw a flow diagram with how the packet *should*
look in the forward and reverse diretion at each
point in the forwarding decision.
ie:
Router
|
A B
A's ip address and mask is?
B's ip address and mask is?
Router's ip address and mask is?
Router's configuration is?
Then, diagram out how the packet will look.
ie: going from B to A:
packet leaves B towards the router with DA,SA of ?
comfing out of the Router towards A the DA,SA should be?
There are two parts that make this confusing:
a) the translation part
and
b) the routing part
I did a dual NAT configuration a few years ago and had saved the
configuration. It would translate the source and destination
addresses with dual NAT.
I've attached it as a reference. I'm not saying it will solve
your problem I'm just giving it as an example. We need
to see more information on what your ip address layout is
and how you are trying to make it work.
Rodney
On Fri, Nov 05, 2004 at 08:24:32PM -0500, Ed Ravin wrote:
> I've managed to set up a test environment with NAT-on-a-stick between
> hosts on the same LAN, based on the kind post from Bruce Pinksy
> and the Cisco NAT-on-a-stick page at
> http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml
>
> However, the examples in both the Cisco pages and Bruce's post below
> only show translation of the destination address, and they only show
> ICMP working. When I try with TCP, the host whose destination address
> has been NAT'd responds directly to the original host, and no NAT takes
> place on the response, so the connection gets reset.
>
> In other words, with ICMP, the NAT-on-a-stick config below does this:
>
> host1 on LAN A -> NAT Address ICMP echo request
>
> The Cisco then catches this via the policy route, turns it into:
>
> host1 on LAN A -> host2 on LAN A ICMP echo request
>
> And host2 responds:
>
> host2 on LAN A -> host1 on LAN A ICMP echo reply
>
> And the "ping" command accepts this response, because "ping" isn't
> too fussy about checking whether the source IP matches the destination
> IP of its original request.
>
> But when I switch to TCP, nothing works. My text box tries to open
> a TCP connection with the NAT address:
>
> host1 on LAN A -> NAT Address SYN
>
> And the Cisco policy turns this into:
>
> host1 on LAN A -> host2 on LAN A SYN
>
> And host2 responds:
>
> host2 on LAN A -> host1 on LAN A ACK
>
> But host1 thought he was starting a TCP connection to the NAT address.
> When host2 responds instead, he resets the connection:
>
> host1 on LAN A -> host2 on LAN A RST
>
> So it's clear that if I'm going to use NAT-on-a-stick for TCP between
> hosts on the same LAN, (i.e. between hosts on the same inside interface),
> I need to get NAT working in both directions.
>
> But how? I've played around with a couple of things but they don't work.
> To translate back into IP numbers, using Bruce's example below, how would
> I get host 116.16.26.6 to open a TCP connection to 10.10.10.10, which
> gets NAT'd to 116.16.26.4?
>
> PS: I'm using a split view DNS for the moment to work around this
> problem, but there are a few other considerations (which I won't bore
> you with here) that require use of NAT.
>
>
>
> On Tue, Oct 26, 2004 at 05:38:12PM -0700, Bruce Pinsky wrote:
> > -----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-----
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list