Help with routing tables

[jaredkipe]

I have been attempting to create a wireless bridge between two buildings using 2 routers (effectively 3).

I've run into a bit of a road block when it comes to routing from one network to the other.

Here are the basics of the configurations

A) 192.168.5.1 (LAN) static route (192.168.6.0/24 -> 192.168.5.254)
^
||
B) 192.168.5.254 (WAN 192.168.5.0/24 -> 192.168.5.1) <-> 192.168.6.25 (LAN)
^
||
C) 192.168.6.1 (LAN) static route (192.168.5.0/25 -> 192.168.6.25)

Here is where it gets interesting. With router (B) configured as a 'gateway' I can access all services on the 5 segment from computers on the 6 segment. (AKA ping from 192.168.6.50 to 192.168.5.20 works)

However computers in the 5 segment cannot ping or talk to computers on the 6 segment.
-------------
If I configure router (B) as a 'router' the situation is reversed. (AKA ping from 192.168.5.20 to 192.168.6.50 works, but not the reverse.)

While (B) is configured as a 'router' I packet sniffed and found the ICMP packets had the correct source and destination hardware addresses (meaning the destination was the hardware address of (B). And the correct IP addresses for source and destination.

I don't know what is going on but I assume I don't have the correct routes on (B).

Any advice?

 

[jdabbs]

That network diagram is confusing.

Router A: WAN: Probably Internet LAN: 192.168.5.1/24
Router B: WAN: 192.168.5.254/24 LAN: 192.168.6.1/24
Router A LAN<>Router B WAN

If that's not your network, my assessment may not be accurate.

B in gateway mode works because it is performing NAT. ICMP requests from C have a source of 5.254. Port forwarding will have to be in place for 5.x devices to access select resources behind B.

For router mode B->A ICMP testing, I recommend running a packet capture on the destination. If Router A LAN subnet clients aren't receiving the ICMP request, Router B is suspect. If they see it and reply, then Router A might be the culprit.

 

[jaredkipe]

That is not the configuration of the network.

There are 3 routers (for a variety of reasons), one router is basically a man in the middle between the two network segments.

I'm aware that as a 'gateway' it is doing NAT, port forwarding is not an option here. I need the two subnets to be able to talk to each other.

The biggest confusion I guess is why when I set it to 'router' it only seems to work in one direction. Namely, addresses in the 5 subnet can talk to addresses in the 6 subnet, but not the other way around.

This isn't just ICMP echos, HTTP traffic and some other stuff functions in one direction, not the other.

 

[jdabbs]

Your network diagram is a confusing mess. Either your diagram is a mess, or your network is a mess. Maybe even both--I can't tell.
Routing problems are hard to pin down without being able to trace the route. This is what other people need to accurately visualize your network:

Router A
WAN IP/subnet:
LAN IP/subnet:
Router B
WAN IP/subnet:
LAN IP/subnet:
Router C
WAN IP/subnet:
LAN IP/subnet:
Router A (WAN|LAN) is connected to Router B (WAN|LAN).
Router B (WAN|LAN) is connected to Router C (WAN|LAN).
NAT on A? (yes|no)
NAT on B? (yes|no)
NAT on C? (yes|no)
Hosts on Router A are using IP X as their gateway.
Hosts on Router B are using IP X as their gateway.
Hosts on Router C are using IP X as their gateway.
Static route on A:
Static route on B:
Static route on C:

Tedious? Yes. The devil lies in the details, and so does salvation.

 

[jaredkipe]

Your network diagram is a confusing mess. Either your diagram is a mess, or your network is a mess. Maybe even both--I can't tell.
Routing problems are hard to pin down without being able to trace the route. This is what other people need to accurately visualize your network:

Tedious? Yes. The devil lies in the details, and so does salvation.

Sorry, I'll try again, thanks for trying to help me here.

Basically A and C are different buildings, with their own internet and their own services etc... Router B is a middle man, that bridges the two networks effectively. B and C are running Tomato firmware, A is Routerboard. Anyone technically connected to B's LAN are basically on C's LAN.

Router A
WAN IP/subnet: some internet/31
LAN IP/subnet: 192.168.5.1/24
Router B
WAN IP/subnet: 192.168.5.254/24
LAN IP/subnet: 192.168.6.25/24
Router C
WAN IP/subnet: some internet/31
LAN IP/subnet: 192.168.6.1/24
Router A (LAN) is connected to Router B (WAN).
Router B (LAN) is connected to Router C (LAN).
NAT on A? (yes) (to internet only?)
NAT on B? (yes|no) (*)
NAT on C? (yes) (to internet only?)
Hosts on Router A are using IP 192.168.5.1 as their gateway.
Hosts on Router B are using IP 192.168.6.1 as their gateway.
Hosts on Router C are using IP 192.168.6.1 as their gateway.
Static route on A: 192.168.6.0/24 -> 192.168.5.254
Static route on B: none by me
Static route on C: 192.168.5.0/24 -> 192.168.6.25

* when NAT is on:
Hosts on C can ping hosts on A
Hosts on A cannot ping hosts on C
when NAT is off:
Hosts on C cannot ping hosts on A
Hosts on A can ping hosts on C

 

[jdabbs]

Yeah, this one is a bit of head-scratcher.
Your network has a solid design--no obvious flaws. Like you, I suspected Router B, but after tracing the packet flow from C hosts to A hosts, I don't think Router B is the culprit. For ping to be successful, you need a bi-directional communications path. The first leg of the C>A ping follows the same path as the return reply of an A>C ping attempt, and vice versa. Since A>C pings successfully return a reply, valid routes exists for at least a subset* of IPs.

Router A could be the problem. Does this router perform ingress filtering? C>A pings may have a packet with a 6.x source passing through an interface that expects 5.x source traffic. It makes sense to filter these packets. There may be another reason for filtering. I know ASA firewalls by default filter packets that would be routed out of the same interface.

This hypothesis is compatible with "C>A (B NAT)" success since the source would appear to be from the 5.x subnet. A>C working can be explained by the A host creating a dynamic table entry in the firewall when the ICMP request is initiated.

This hypothesis can be disconfirmed by Router B and A hosts being directly connected (feeding into the same switch, for example). Observing an ICMP request on an A host would also suffice.

*a mismatched subnet scenario could explain why pings work in one direction but not another. As long as how you think the network is laid out and how it actually is are the same, and your hosts are configured with /24 masks, you shouldn't have to worry about this.

 

[jaredkipe]

You nailed it on the filtering/NAT'ing from RouterA.

Thank you for your help!