[CUWiN] nat bogosity (was: circular route)

simon-cuw at uc.org simon-cuw at uc.org
Fri Jan 20 12:08:08 CST 2006


(Please excuse me if I say something rediculous, I've only had experience with
simple NAT'ing so far)

I don't quite see how that mapping would help this scenario. If we look at the
existing NAT table on Node A, we see:

# ipnat -l
List of active MAP/Redirect filters:
1: rdr sip0 192.168.0.1/32 port 80 -> 127.0.0.1 port 80 tcp
2: map sip0 10.0.0.0/8 -> 192.168.42.22/32 portmap tcp/udp 10000:20000
3: map sip0 10.0.0.0/8 -> 192.168.42.22/32

This allows all nodes connected to Node A to have internet access via Router A,
but prevents all clients on LAN A access to the mesh network.

If sip0's self-assigned subnet is 10.216.111.0/24, with IP 10.216.111.254,
alias 192.168.42.22, and default gw 192.168.42.1, your suggestion would become:

4: map ath0 192.168.42/24 -> 10.216.111/24 portmap tcp/udp 10000:20000
5: map ath0 192.168.42/24 -> 10.216.111/24

If I understand correctly, rules 2-3 would conflict with 4-5, right?

...

Putting that aside, with the existing cuwireless software, would the ideal
scenario be to add a 3rd node, Node N, handling DHCP for LAN A, and providing
internet connectivity for LAN A, Node A and beyond?

(internet)--sip0(Node N):sip1--<LAN A>
                  sip2
                   |
                    \-----(Node A)~~~(Node Z)--<LAN Z>

On Fri, 20 Jan 2006, David Young wrote:

> On Fri, Jan 20, 2006 at 12:07:56AM -0500, simon-cuw at uc.org wrote:
> > Hello,
> >
> > I have the following setup:
> > (internet)--(Router A)--<LAN A>--(Node A)~~~(Node Z)--<LAN Z>
> >
> > - Router A provides DHCP for LAN A
> > - Node Z provides DHCP for LAN Z
> > - A computer on LAN A has a static route for LAN Z pointing to Node A'a
> >   address on LAN A.
> >
> > I can ping from computesr on LAN Z to LAN A, but trying to do the
> > opposite, pinging form LAN A to LAN Z seems to reveal a circular route
> > somewhere. Any ideas how I could start troubleshooting this?
> >
> >
> >
> > i.e.:
> >
> > Node A = 192.168.42.22, on 192.168.42.0/24, internet/dhcp from linksys rtr
> > Node Z = 10.216.103.254, on 10.216.103.0/24, dhcp from cuw node
> >
> > mylaptop_on_A$ sudo route add -net 10.216.103.0/24 gw 192.168.42.22
> >
> > mylaptop_on_A$ ping 10.216.103.252
> > PING 10.216.103.252 (10.216.103.252) 56(84) bytes of data.
> > 64 bytes from 192.168.42.22: icmp_seq=1 ttl=62 time=7.12 ms
> > 64 bytes from 192.168.42.22: icmp_seq=2 ttl=62 time=4.37 ms
> > 64 bytes from 192.168.42.22: icmp_seq=2 ttl=62 time=4.37 ms
>
> It's NAT bogosity: note the reply comes from 192.168.42.22 instead of
> 10.216.103.252.
>
> When a node gets a lease on an RFC1918 address on its ethernet, maybe
> it should map the RFC1918 subnet to its self-assigned ethernet subnet,
> 10.x.y/24.  E.g., add a NAT rule for each ethernet,
>
>         map ath0 192.168.42/24 -> 10.x.y/24 portmap tcp/udp 10000:20000
>         map ath0 192.168.42/24 -> 10.x.y/24
>
> They say "NAT is eeeevil" for a reason.
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless mailing list
> CU-Wireless at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless
> Project Page: http://cuwireless.ucimc.org
>


More information about the CU-Wireless mailing list