<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: RE: Cipe and masquerading.
From: "Bort, Paul" <pbort,AT,tmwsystems,DOT,com>
Date: Thu, 26 Sep 2002 00:13:15 +0200

> 
> Having a different box doing the NAT and the CIPE seems work,
> letting the same box do it not.

Don't tell my servers, they've been doing it for years. Really. It's much
easier to do all of the routing for one ethernet segment at one default
gateway, instead of having to add a route for the network on the far side of
the tunnel to each machine. 

> 
> The traffic between C and D is not NAT'ed.  C does NAT/MASQ going
> on the internet.  The cipe tunnel should then be NAT'ed over the
> internet to host B.

So D can SSH to B (presumably through C) without being NAT'ed or going over
the CIPE tunnel? How? Being able to SSH between two hosts is a good first
test before trying to construct a CIPE tunnel between them, because it
doesn't forgive NAT or masquerade, but does forgive routing/packet
forwarding/bridges. This profile matches CIPE exactly, IIRC.

When CIPE says it's a tunnel, it's not kidding. There's no way out in the
middle, and there's no changing addresses along the way. Your routing has to
reflect this.

You don't mention what addresses you're using for your CIPE tunnel
endpoints, but I've had the best luck with both endpoints in a separate
subnet.

> 
> Maybe an example with more info about what data should go between
> what hosts would help.
> 
> This is how I think it should work:
> 
> Example:
> Host A: 10.0.0.2
> Host B: 10.0.0.1
>         1.2.3.4
>         <internet>
> Host C: 4.3.2.1
>         10.0.1.1
> Host D: 10.0.1.2
> Host E: 10.0.1.3
> 
> Maybe I should give host D two interfaces too, but it's not needed
> for this example.
> 
> Host A sends a packet (icmp echo request) to host E.
> 
> Data the hosts sends, each line contains the next "layer".
> Host A: IP: source: 10.0.0.2, dest: 10.0.1.3
>       icmp
> Host B: IP: source: 1.2.3.4, dest: 4.3.2.1, 
>       UDP (cipe): source: 1025, dest: 1026
>       IP: source: 10.0.0.2, dest: 10.0.1.3    
>       icmp

How did the destination of the outer packet become 4.3.2.1? Is there a route
on B like "10.0.1.0/24 via 4.3.2.1"? Shouldn't that route really show the IP
address of the other end of the tunnel as the target? 

> 
> Host C: IP: source 1.2.3.4, dest: 10.0.1.2
>       UDP (cipe): source: 1025, dest: 1026
>       IP: source: 10.0.0.2, dest: 10.0.1.3
>       icmp

How did C make the destination of this packet 10.0.1.2? Is there
source-based routing on C to forward packets from 1.2.3.4 to 10.0.1.2
without masquerading?

> 
> Host D: IP: source: 10.0.0.2, dest: 10.0.1.3
>       icmp
> 
> Then host E replies with an icmp echo reply:
> Host E: IP: source: 10.0.1.3, dest: 10.0.0.2
>       icmp
> Host D: IP: source: 10.0.1.2, dest: 1.2.3.4
>       UDP (cipe): source: 1026, dest: 1025
>       IP: source: 10.0.1.3, dest: 10.0.0.2
>       icmp
> Host C: IP source: 4.3.2.1, dest: 1.2.3.4
>         UDP (cipe): source: 1026, dest: 1025
>         IP: source: 10.0.1.3, dest: 10.0.0.2
>         icmp
> Host B: IP: source: 10.0.1.3, dest: 10.0.0.2
>       icmp
> 
> 
> Kurt
> 

If you think of each end of the CIPE tunnel as a network adapter separate
from the physical adapter that is carrying the packets, this gets much
easier. You don't specify the IP addresses of those adapters on either B or
D. Putting them on a separate subnet also helps keep this clear, and makes
routing easier. I'm also concerned about the source-based route required on
C to forward the CIPE packets to D. Separating that from NAT and
masquerading would be very interesting. 

What works here is not much different, except that C and D are combined. 

Host A: 192.168.5.20

Host B: 192.168.5.40 (eth0 - inside)
        192.168.7.1  (cipcb0 - tunnel endpoint)
        1.2.3.4 (eth1 - outside)

Host C: 192.168.6.1 (eth0 - inside)
        192.168.7.2 (cipcb0 - tunnel endpoint)
        4.3.2.1 (eth1 - outside)

Host D: 192.168.6.5

B's routing: 
192.168.5.0/24 via 192.168.5.40 dev eth0
192.168.7.0/24 via 192.168.7.1 dev cipcb0
192.168.6.0/24 via 192.168.7.2
default via 1.2.3.4

C's routing: 
192.168.6.0/24 via 192.168.6.1 dev eth0
192.168.7.0/24 via 192.168.7.2 dev cipcb0
192.168.5.0/24 via 192.168.7.1
default via 4.3.2.1

Both B and C do a pile of masquerading inbound, and NAT for all outbound. By
putting the CIPE tunnel on the firewall, it is no longer "outbound", just
routed across the tunnel to the other side.





<< | Thread Index | >> ]    [ << | Date Index | >> ]