Hey all,

I'm wondering if anyone has some ideas on this... sorry for the long post

I have 2 NAT boxes. Each box is connected to the Internet differently. As such, 99% of requests go through box 1. But, box#2 is connected to a special network that must be used to contact the second network (vpn stuff).

I've added a route on NAT box 1 to use box 2 for requests to this special network. And, if I'm on box #1 and ping and IP for this special network, it correctly goes through box #2.

However, if I go to any workstation on the internal network that uses box#1 as default gw and attempt to ping a server on this special network, it correctly gets the ICMP redirect to the new gateway, but never actually uses it. I've tried this on NT and Linux workstations.

I've dropped all necessary firewalls for this test. I've also made sure that accept_redirect is enabled and secure_redirect and send_direct is off on my Linux workstation. I also made sure that send_redirect is enabled and secure_redirect/accept redirect is off on my #1 nat box.

With tcpdump I see something like this on the NAT server:
eth1 < 192.168.3.13 > 192.168.200.1: icmp: echo request
ech1 > 192.168.4.135 > 192.168.3.13: icmp: redirect 192.168.200.1 to host 192.168.0.2 [tos 0xc0]

On the Linux workstation I see almost the exact same thing. For the ping results I see something like this:
From gateway1 (192.168.4.135): Redirect Host (New nexthop: gateway2 (192.168.0.2))

And that's it... a quick check in route -n -C shows the route for the special network IP going to the wrong gateway. I've flushed the table manually, and the same wrong route appears after each test.

So, what else should I add. I've already added the extra route to the extra network on Nat#1. I doublechecked the send/accept_redirect flags in /proc. And, if I manually add the route for the Nat#2 on any of the workstations, I *can* successfully ping the special network. Also, I really don't want to go to each workstation and add a second gateway manually. I was kinda hoping this icmp redirect would do it for me. I realize it'll generate more traffic. It's not that big a deal right now...

It seems like the Nat#1 isn't sending a correctly configured icmp_redirect (since neither NT nor Linux will use it). But, I can't see anything else wrong.... does this require some extra kernel option to work correctly? Any ideas? I've tried the NAT#1 on RH6.2 with 2.2.14-5.0 kernel, and the lastest 2.2.19 kernel -- same results.

Thanks for any help

Jon

Don't worry about the long question, it's better to supply as much info as possible here, rather then been vague about it.
ok lets see, a quick overview of how redirect works.

Note: The Router that's creating the redirect ICMP message must be on the same subnet, i.e you can't have any hops before the redirect router.

What does it do.
You use a Win client which connects to the private address, it uses its default gateway and talks to the Nat1 router.
The Nat1 router forwards the first packet to the Nat2 router because of it's shorter path to destination route.
Nat1 then replies with a ICMP redirect error to the source "client" telling it of a new path.
Client then updates the routing table and connects directly to the NAT2 router.

Right if the client doesn't update it's routing table it cause it's not accepting source routing as default.
Note: NT4 sp4 and below won't work without a patch anyway. (a Micro$oft thing)
Also this is a security risk so all default installations have source routing off as default.

You need to enable it on the client.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value Name: DisableIPSourceRouting
Data Type: REG_DWORD
Value: 0 , 1 or 2
Note: 0 - enables source routing
1 - disables source routing when IP forwarding is also enabled
2 - disables source routing completely (recommended for best security)

on linux client: "The Nat1 & Nat2 don't need this as it knows the static route"
sysctl -a | grep "source"
sysctl -w net.ipv4.conf.all.accept_source_route=1
-----------

That's my guess anyway.
/Raz

Hey,

Raz, I found the default options for the individual adapters for source routing is 1 (global default is zero). But, I changed them all to 1 and still no go.

After thinking about it, I realized what it was... networking/routing problem on my end. I have a real IP address assigned to each machine on my network. But, some of those machines also have virtual IPs for misc reasons -- mainly so that I can move an IP service w/o having to mess w/ the server connection itself.

Well, I had a virtual IP assigned to my NAT box. But, the routing was returing the icmp redirect from the REAL ip of that server. Linux client must have a some sort of table somewhere that checked and found the redirect coming from a host it didn't talk to in the first place. I changed the gw to the real IP of the NAT box and all works as expected.

So, now I'm wondering why the NAT box didn't return the ICMP redirect using the return IP from the source packet (the virtual host IP, not the real host IP)? Bug/feature in tcpip? Both IPs (virtual/real) are on the same subnet. If I had put a service like http on the extra IP the data would have been returned w/the source IP of the virtual IP. So, why not icmp redirect? hmm...

Even a regular icmp_request/reply works w/the virtual IP address...

Thanks for the help

Jon