RRAS static routing problem

  • Thread starter Thread starter p.j.le.r
  • Start date Start date
P

p.j.le.r

A RAS server solution which has been running for several years on NT4
refuses to route with Win2k client and Win2k3 RRAS server.

We have:
- A PIX firewall between the back office LAN and a RAS LAN segment. It
performs static NAT between the two. The RAS LAN is 10.10.192/18. The
PIX is 10.10.200.192.

- A Win2k3 RRAS server, 10.10.200.194, with:
-- a static pool 10.10.200.0...15 for dial-in laptops, which work ok
-- a dial-in connection from an area office system consisting of a
couple of servers and a few terminals, on a subnet 10.10.225.64/26. At
the area office, a Win2k RAS client dials the RRAS server requesting
specific IP address 10.10.200.63.

After the first dial-up, a route add command:
route add 10.10.225.0 mask 255.255.255.0 10.10.200.63 if 0x10002
is issued from a command prompt. RRAS doesn't let me set this up as a
static route since the dial-up connection doesn't exist at the time.
On NT, it worked fine. The route survives successive dial-in sessions
both on NT and Win2k3

Extensive tests with ping and ethereal show that the problem is that
when the PIX does an ARP request for a 10.10.225 address, the RAS
server should respond since it has a route, but it doesn't. It worked
fine under NT.

Any ideas how to fix it?

Ta - Philip
 
Things changed a bit between NT and W2k. See KB 254231 (particularly
the note near the end).

Rather than using a script to add the route, you can use the technique
that LAn to LAN routing uses. Set up a demand-dial interface on the server
and link the route to the interface (using the static route interface). Then
dial up using the dd interface name as the username. (You will need to
create an account for it with dialup permissions). The connection will be
made to the dd interface and the route activated.

What you are really doing is using the dd interface name as a symbolic
name for the connection, so that you can link routes to it before the
connection is made. When you do connect the system adds the route (which has
been stored in the registry) to the routing table.
 
Bill -

Thanks for an excellent reply. I eventually got a connection after
dissociating the dial-in user from the dial-in policy and configuring
the port for demand dial routing, but it still doesn't route - see
later. Also, I can't see how to independently enable/disable dial-in
and -out except by setting empty dial-out hours. And it seems there
ought to be a linkage between ports and interfaces, which eludes me.

Alternatively, couldn't I set up a static IP address and static route
in the dial-in properties of the user? I can get a connection like this
but as in the above config, the RAS server still fails to respond to
arp requests for the route. "Route print" shows the route. This config
might be preferable because the client needs to be easily
reconfigurable between roles as a dial-in router and a dial-in
application terminal.
 
There is no problem with reconfiguring the client. If it dials in using
the demand-dial interface name, it connects as a router. If it dials in
using a name which does not match a demand-dial interface it connects as a
normal dialup client. That's how RRAS knows what type of connection to set
up.
 
I should have added that the routing will only work if there is a static
route tied to the demand-dial interface and that you actually connect to
that interface.

A normal "dialup" client connection sets a default route to the RRAS
server, but the RRAS server itself only sets up a host route back to the
caller (so it won't route to the subnet behind the caller). You connect to
the default internal interface.

If you actually connect to the demand-dial interface you can get a
subnet route back through the connection.
 
I think I now have a much clearer understanding of RRAS, but the
problem seems to be more fundamental: the RRAS server is not responding
to ARP requests for IP addresses (within its LAN subnet) that it has a
route to.

The RRAS server and the firewall in front of it are 10.10.200.192 and
193, on a subnet with mask 255.255.192.0.

The PPP server is 10.10.200.0 and assigns 10.10.200.63 to the client.

The branch office is 10.10.225.64 mask 255.255.255.224, and a route to
it is associated with the PPP link. A netstat -r command shows the
route.

A branch office host pings the firewall. The echo request hits the
firewall which then issues an ARP request for the originator. The RRAS
server should respond, having a return route, but doesn't. Why???
This has been the basic problem all week.
 
I am not too sure why you are worried about ARP. That is quite different
from routing. If you are using the same IP subnet for both the LAN and the
clients, no "real" IP routing is done. The server forwards the packets on to
the LAN and does proxy ARP for the clients. That means that the remote
client appear to be on the same segment, because the server answers ARP
requests on the LAN for the clients. When it gets the packet it forwards it
across the PPP/PPTP link to the client. This is fine for a "dialup" or
client-server connection. It doesn't work for a site to site connection.

For a site to site (or LAN to LAN) connection, the two sites are in
different IP subnets and the traffic is routed through the link. ARP
operates within each LAN, not across the link.

I actually prefer to put the remotes in their own subnet and route the
traffic through the RRAS server, even for client-server connections. Some
switches don't handle proxy ARP in the same way that hubs do.
 
I agree with Bill's post, but here's some stuff I'd written before I saw
his.

The RRAS server and the firewall in front of it are 10.10.200.192 and
193, on a subnet with mask 255.255.192.0.

The PPP server is 10.10.200.0 and assigns 10.10.200.63 to the client.

The branch office is 10.10.225.64 mask 255.255.255.224, and a route to
it is associated with the PPP link. A netstat -r command shows the
route.
[/QUOTE]
I would never do that myself and some might even go so far as to call it
illegal. You have two distinct LAN segments, but their address ranges
overlap. Yuck.

Some systems will cope with that and others won't, and I think that's
what you are finding here. Probably for good safety reasons, RRAS is
maybe not willing to Proxy ARP for devices that are both not directly
attached nor for which it hasn't assigned addresses(?).

(What is the effective configuration of the remote 'router';
10.10.192.63/18 on the WAN interface and 10.10.225.x/18 on the LAN
interface. Doesn't it get confused? For routing it just obeys the
default route of next-hop-interface=WAN I suppose).
A branch office host pings the firewall. The echo request hits the
firewall which then issues an ARP request for the originator. The RRAS
server should respond, having a return route, but doesn't. Why???
This has been the basic problem all week.
Click to expand...
Secondly, Proxy ARP can be useful but it shouldn't be overused (I
disable its existence where possible). It is only 'necessary' where a
RAS device is assigning addresses from the subnet of its attached
LAN to dial-in devices. When 'routing' to a remote segment then that's
really the job of routing, and not ARP (IMO).


Anyway, imagine for a second what would be required if the remote
segment had a distinct address range and didn't steal addresses from the
local LAN (which would be better, as Bill notes and maybe you should
think of doing so now). Then a route would be required on the PIX
telling it to use the RRAS box as the next hop. I think that this will
work here too, so just add a route of 10.10.255.64/26[1] to the PIX with
the next hop the RRAS box's LAN address[2].

Of course if there are other devices attached to the local LAN then you
may need to do more...


notes
[1] From your post of the 19th, or here "10.10.225.64 mask
255.255.255.224" i.e. /27.
[2] 10.10.200.194 from the 19th, or 10.10.200.192 here.
 
The problem is that proxy arp doesn't work in win2k quite like NT4.
(Why Mr Gates should want to change it is a mystery.) Googling "windows
2000 proxy arp" indicates that this has been a problem for Checkpoint
Firewall-1 moving from an NT4 to Win2k base and trying to make it
accept IP packets for static NATted addresses. Checkpoint have produced
a utility fwparp available from their site only to registered users,
but I found a copy elsewhere (you may find it as a zip or an exe). It
only allows you to create a proxy arp entry for one address at a time,
so is of limited value for a subnet, but it seems to use the
CreateProxyArpEntry API which does allow you to specify a subnet.

I could set up a static arp entry on the PIX firewall that originally
issued the arp request, but that will mysteriously stop working if an
engineer replaces the network card in the RRAS server in 2 or 3 years
time when I've moved on to another project. (You can imagine how long
that might take to diagnose!)

So it's a question of whether to rearrange my subnets, or hack a bit of
C code to call CreateProxyArpEntry. Now, where's that network diagram
under all these bits of paper?
 
Back
Top