[LARTC] Routing with SNAT

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 24 Feb 2002, bert hubert wrote:

> > - I want the wireless NAP to connect to my DSL (ARM pppoe just isn't
> > there yet).
> 
> No? The stuff in the kernel seems very generic and works tremendously well.
> 

That is if you use a kernel mode pppoe package. rp-pppoe, the package that
comes with RedHat and ARM debian, is a user space program. It has some
problems because the ethernet frames are not packed properly for ARM as
well as a few other things. I tried a kernel mode package but it was meant
for older (read 2.2 kernels) and used a deprecated call somewhere. I tried
about 5 different packages all with varying degrees of not working. :)

> > - I want the netwinder right behind the NAP and fully open to the
> > internet (this is achieved using the NAP's DMZ feature)
> > - The netwinder will run netfilter doing my packet filtering, NAT, and
> > traffic shaping
> > - The netwinder will also be connected to a hub
> > - All machines behind the netwinder will connect to the hub and use the
> > netwinder's NAT to gain net
> 
> 
> Can people please draw a picture? It's not that hard and it makes it lots
> easier to see what you want. Anybody wanting to answer this question now has
> to draw this (mental) picture first, making the people who you want answers
> from do the work :-)
> 
>          ARM - NAP  - DSL 
>           |
>        -------
>        x x x x
> 

Sorry... :)

> > On the intel machine which has address 192.168.1.2 I try to ping 2.3.4.5
> > (an outside IP). I have root access on 2.3.4.5 so I put the ethernet
> > interface into promiscuous mode and run "tcpdump -i eth0 -p icmp". On
> > the netwinder I put eth0 into promiscuous mode and do the same. What I
> > see is that the netwinder sees the outgoing ICMP requests with my static
> > ip (1.2.3.4). 2.3.4.5 sees the request coming from 1.2.3.4 and sends
> > replies. The netwinder never sees the replies. What I've gathered is
> > that the netwinder needs to broadcast that it is the route for 1.2.3.4
> > so that these return packets get past the NAP and routed to the
> > netwinder. In my searching I haven't found how to do this. Can anyone
> > let me know how this might be achieved or let me know the proper way to
> > get this working? Thanks!
> 
> What you did is invent an IP address :-) Your ISP shouldn't even let a
> packet with source 1.2.3.4 go out, unless that IP address is *yours*.
> 
> In this case, you should change 1.2.3.4 to an address that is routed to you,
> or ask your ISP to route one to you.
> 
> To see what I mean, traceroute to 1.2.3.4 from 2.3.4.5 and you will that
> packets aren't even going near you.

So in my case I was snat'ing the packet to contain my DSL static IP
1.2.3.4. I figured out that the problem is that the wireless NAP was doing
some NATing of its own so that packets that came from 192.168.123.1 were
routed properly because the NAP had knowledge of where they came from but
the packets that were NATed to have the 1.2.3.4 address passed through the
NAP because it didn't know how to NAT those, so when they return the NAP
just dropped/accepted the packets thinking they were for it since there
was none of its NAT info attached. (Man, is it confusing to talk about NAT
over a NAP!). So, on my ARM machine, I just masqueraded the packets so
that they all appeared to be coming from the ARM machine so the wireless
NAP would then route everyting back through the ARM on return. Basically,
two levels of NAT. Thanks and sorry for not trying this originally.


-Ti



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux