Re: Transparent broadband network connectivity (IP PnP)

Re: Transparent broadband network connectivity (IP PnP)

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 5002 bytes --]

On Thu, Mar 13, 2003 at 10:10:28AM +0700, dragon_nlt@yahoo.com wrote:
> Sorry, it's me again. I don't think my question is simple
> usage/configuration question. It's really need a professional support. It's
> greatly appreciated if you can help me some.

'professional' was meant to translate to 'commercial', 'being paid' ;)

Anway.  This question would belong to the devel list, so I'm Cc'ing it
with a fullquote attached. Hope you don't mind.

The netfilter/iptables implementation does not support broken network
configurations like the one you describe.  From my perspective, people
should use some autoconfiguration mechanism like DHCP.  I think it's the
wrong way to not expect the end user to at least know how to activate DHCP
on a network interface.

A broken setup like you describe breaks about any of the fundamental
assumptions of a working IP network. (and of layering in a network)

Even though there are commercial products trying to provide service to a
broken network, this doesn't meen that netfilter/iptables should do the
same horrible kludge.

> >Date: Thu, 13 Mar 2003 09:43:50 +0700
> >To: laforge@gnumonks.org
> >From: dragon_nlt@yahoo.com
> >Subject: RE: Transparent broadband network connectivity (IP PnP)
> >
> >Hi,
> >
> >Maybe you will misunderstand my question. So i will describe the problem
> >in detail.
> >
> >This is the implementation for such a public internet access network like
> >airport, hotel, ... So the client IP address can be any thing. The main
> >point is that a client just only need to plug into the net then he can
> >surf internet without changing his ip configuration.
> >I found some commercial products for this such as IP PnP
> >(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
> >(http://www.demarctech.com/products/reliawave-rwh/reliawave-ipnpsg.html)
> >(Please see Address Translate Function section). I wonder that iptables
> >itself can do it or not.
> >
> >With iptables, we can nat outgoing traffic, but the problem is that
> >clients inside internal network can be any IP address (different subnet,
> >netmask, gateway, dns ... and even thought clients have the same IP). I
> >think there is needed a layer-2 NAT, e.g. handling clients which may have
> >any IP address (even the same IP address), etc. correctly. I found a
> >useful thread here
> >http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
> >
> >For example
> >
> >Client 1 -----------|
> >192.168.10.5        |
> >                     |  172.16.1.1  PublicIP
> >Client 2 -----------|        eth0    eth1
> >DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
> >                     |  DefaultGW=RouterIP
> >Client 3 -----------|
> >200.192.16.10       |
> >                     |
> >Client 4 -----------|
> >64.12.5.12
> >
> >I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
> >to set it as the gateway for all clients, and use iptables SNAT target
> >inside nat POSTROUTING chain of eth1.
> >
> >iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source <eth1 ip>
> >
> >When client send a packet out, the packet goes into eth0, goes through
> >forward chain after routing decision, get nat'd on eth1 then send to the
> >router. The problem is that when the reply packet from router goes back
> >eth1, after de-nat'd, the packet will be sent to the eth1 following the
> >default route on gateway box instead of eth0 (since client can have any
> >ip, so we can't set the routing table; default gateway is router's ip via
> >eth1). I think there is needed such a MAC based NAT module on PREROUTING
> >chain of eth0. So the gateway will don't care about client IP, just client
> >MAC address (assume that MAC address is unique). Do you have any idea?
> >
> >Best Regards,
> >
> >John Duke
> >
> >>Date: Wed, 12 Mar 2003 18:55:21 +0700
> >>To: laforge@gnumonks.org
> >>From: dragon_nlt@yahoo.com
> >>Subject: Transparent broadband network connectivity (IP PnP)
> >>
> >>Hello,
> >>
> >>Can you let me know if netfilter can allow clients inside Internal
> >>network (can be any ip) access Internet by using NAT?
> >>
> >>Internal-network --- [ gateway ] --- Internet
> >>  (any ip)
> >>
> >>
> >>There is a product called IP PnP
> >>(http://www.infino.co.kr/infino/eng/softpackage_e.php) provide that
> >>feature but I'm looking for an opensource solution. Do current netfilter
> >>can do it or I need to hack some netfilter code?
> >>
> >>Looking forward to your reply,
> >>
> >>Best Regards,
> >>
> >>John Duke
> 
> 

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Transparent broadband network connectivity (IP PnP)

[Ilguiz Latypov]

On Thu, 13 Mar 2003, Harald Welte wrote:

> A broken setup like you describe breaks about any of the fundamental
> assumptions of a working IP network. (and of layering in a network)

Not to start a flame war, but I think the only missing part in that
"broken" network topology was the automatic addition/removal of host
routes on the gateway pointing to eth0 for any packets destined to the
clients' IP addresses.

SNAT-ting would still be required, as it was shown in the original
message.

--
Ilguiz Latypov
Net Integration Technologies, Inc

tel. +1 (514) 281 9191 x 117

Re: Transparent broadband network connectivity (IP PnP)

[Patrick McHardy]

>
>
>>>Date: Thu, 13 Mar 2003 09:43:50 +0700
>>>To: laforge@gnumonks.org
>>>From: dragon_nlt@yahoo.com
>>>Subject: RE: Transparent broadband network connectivity (IP PnP)
>>>
>>>Hi,
>>>
>>>Maybe you will misunderstand my question. So i will describe the problem
>>>in detail.
>>>
>>>This is the implementation for such a public internet access network like
>>>airport, hotel, ... So the client IP address can be any thing. The main
>>>point is that a client just only need to plug into the net then he can
>>>surf internet without changing his ip configuration.
>>>I found some commercial products for this such as IP PnP
>>>(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
>>>(http://www.demarctech.com/products/reliawave-rwh/reliawave-ipnpsg.html)
>>>(Please see Address Translate Function section). I wonder that iptables
>>>itself can do it or not.
>>>
>>>With iptables, we can nat outgoing traffic, but the problem is that
>>>clients inside internal network can be any IP address (different subnet,
>>>netmask, gateway, dns ... and even thought clients have the same IP). I
>>>think there is needed a layer-2 NAT, e.g. handling clients which may have
>>>any IP address (even the same IP address), etc. correctly. I found a
>>>useful thread here
>>>http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
>>>
>>>For example
>>>
>>>Client 1 -----------|
>>>192.168.10.5        |
>>>                    |  172.16.1.1  PublicIP
>>>Client 2 -----------|        eth0    eth1
>>>DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
>>>                    |  DefaultGW=RouterIP
>>>Client 3 -----------|
>>>200.192.16.10       |
>>>                    |
>>>Client 4 -----------|
>>>64.12.5.12
>>>
>>>I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
>>>to set it as the gateway for all clients, and use iptables SNAT target
>>>inside nat POSTROUTING chain of eth1.
>>>
>>>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source <eth1 ip>
>>>
>>>When client send a packet out, the packet goes into eth0, goes through
>>>forward chain after routing decision, get nat'd on eth1 then send to the
>>>router. The problem is that when the reply packet from router goes back
>>>eth1, after de-nat'd, the packet will be sent to the eth1 following the
>>>default route on gateway box instead of eth0 (since client can have any
>>>ip, so we can't set the routing table; default gateway is router's ip via
>>>eth1). I think there is needed such a MAC based NAT module on PREROUTING
>>>chain of eth0. So the gateway will don't care about client IP, just client
>>>MAC address (assume that MAC address is unique). Do you have any idea?
>>>
>>>Best Regards,
>>>
>>>John Duke
>>>      
>>>

I guess you could use conntrack match with --orig-dst and ROUTE target 
to force packets
out the "correct" interface. You probably still need to do some things 
to make linux send
arp requests for these ips.

Patrick

Re: Transparent broadband network connectivity (IP PnP)

[Ian Latter]

Hmmm ....

  Yes .. you need to fix the laptops' routing ....  if we're not dhcp'ing all 
of these people (which would be the first thing I'd do), then you're stuck
with an internet's worth of IP addresses, masks and gateways ... from
private to public.  So getting the traffic to your linux gateway is the first
problem.   ie;
   user1 = 10.1.1.99 / 255.255.0.0 - gw 10.10.0.12
   user2 = 192.168.27.149 / 255.255.255.0 - gw 192.168.27.254
   user3 = 1.2.3.200 / 255.0.0.0 - gw [not set]   (user3 has a www
                                                                           server at 1.1.1.1)

  What you probably want to do is a layer2 fudge ... where, whatever
they arp for, you give them the linux box; this will then sort out all of
your routing issues ... ie;
  user1 = arp for 10.10.0.12 ... ans = LI:NU:XM:AC
  user2 = arp for 192.168.27.254 ... ans = LI:NU:XM:AC
  user3 = arp for 1.1.1.1 .... ans = LI:NU:XM:AC


  Once they're at the linux router/firewall doohicky, they can then
be universally NAT the traffic .... but then you've got a problem ... 
because the linux box, doing routing, will send user data back to
the internet.  You can fix this by doing one of two things;
  1.  Whatever does the arp spoofing to correct the routing, should
       also rarp the ips of the macs currently asking for arps.  This
       would allow you to layer2 correct the linux box.  this box would
       have a default route to the net.

  2. You could use two linux boxes.  The first (closest to the users)
      would have to do all of the layer 2 work - and then forward (bridge)
      traffic to the second.  The second would have to do ip NATing
      when matching the from MAC ... I think ... I haven't done any layer 2
      stuff in iptables.  second box has default route of the net.

Go with 1.

One problem you'll have with the layer 2 spoofing is that one day the
guy with www.intel.com on his laptop may arrive ... and he may choose
to respond to his own arp requests ... as unlikely as this at first may
appear to be  ... I'm sure its something that will bite you in the ass when
you least want it to (on reflection, if he did arrive and did respond to his
own arps, then you'll be the only guy in the world with the correct 
routing ;-))

Honestly though ... your best bet is DHCP ... most people expect it .. and
a lot of corporate networks are configured for it (meaning that the lappy
owners don't have to change their config to plug into you).

If you do find a way to do the arp and rarp work properly, then let me 
know ... I'd like to keep that one in my repetuar ...



----- Original Message -----
>From: "Patrick McHardy" <kaber@trash.net>
>To: 
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Thu, 13 Mar 2003 20:19:16 +0100
>
> >
> >
> >>>Date: Thu, 13 Mar 2003 09:43:50 +0700
> >>>To: laforge@gnumonks.org
> >>>From: dragon_nlt@yahoo.com
> >>>Subject: RE: Transparent broadband network connectivity (IP PnP)
> >>>
> >>>Hi,
> >>>
> >>>Maybe you will misunderstand my question. So i will describe the problem
> >>>in detail.
> >>>
> >>>This is the implementation for such a public internet access network like
> >>>airport, hotel, ... So the client IP address can be any thing. The main
> >>>point is that a client just only need to plug into the net then he can
> >>>surf internet without changing his ip configuration.
> >>>I found some commercial products for this such as IP PnP
> >>>(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
> >>>(http://www.demarctech.com/products/reliawave-rwh/reliawave-ipnpsg.html)
> >>>(Please see Address Translate Function section). I wonder that iptables
> >>>itself can do it or not.
> >>>
> >>>With iptables, we can nat outgoing traffic, but the problem is that
> >>>clients inside internal network can be any IP address (different subnet,
> >>>netmask, gateway, dns ... and even thought clients have the same IP). I
> >>>think there is needed a layer-2 NAT, e.g. handling clients which may have
> >>>any IP address (even the same IP address), etc. correctly. I found a
> >>>useful thread here
> >>>http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
> >>>
> >>>For example
> >>>
> >>>Client 1 -----------|
> >>>192.168.10.5        |
> >>>                    |  172.16.1.1  PublicIP
> >>>Client 2 -----------|        eth0    eth1
> >>>DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
> >>>                    |  DefaultGW=RouterIP
> >>>Client 3 -----------|
> >>>200.192.16.10       |
> >>>                    |
> >>>Client 4 -----------|
> >>>64.12.5.12
> >>>
> >>>I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
> >>>to set it as the gateway for all clients, and use iptables SNAT target
> >>>inside nat POSTROUTING chain of eth1.
> >>>
> >>>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source <eth1 ip>
> >>>
> >>>When client send a packet out, the packet goes into eth0, goes through
> >>>forward chain after routing decision, get nat'd on eth1 then send to the
> >>>router. The problem is that when the reply packet from router goes back
> >>>eth1, after de-nat'd, the packet will be sent to the eth1 following the
> >>>default route on gateway box instead of eth0 (since client can have any
> >>>ip, so we can't set the routing table; default gateway is router's ip via
> >>>eth1). I think there is needed such a MAC based NAT module on PREROUTING
> >>>chain of eth0. So the gateway will don't care about client IP, just client
> >>>MAC address (assume that MAC address is unique). Do you have any idea?
> >>>
> >>>Best Regards,
> >>>
> >>>John Duke
> >>>      
> >>>
> 
> I guess you could use conntrack match with --orig-dst and ROUTE target 
> to force packets
> out the "correct" interface. You probably still need to do some things 
> to make linux send
> arp requests for these ips.
> 
> Patrick
> 
> 
> 
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: Transparent broadband network connectivity (IP PnP)

[Ian Latter]

Clarifying this ...  correcting 1 and 2 below;

  Once they're at the linux router/firewall doohicky, they can then
be universally NATed .... but then you've got a problem ... because
the linux box, doing layer-3 routing, will send user data back to the
internet.  You can fix this by doing one of two things;

  1.  Whatever does the arp spoofing to correct the routing, should
       also rarp the ips of the macs currently asking for arps.  This
       would allow you to layer-2 correct/align the linux box.  ie;
            rarp on 10.1.1.99 = US:ER:1M:AC
            rarp on 192.168.27.149 = US:ER:2M:AC
            rarp on 1.2.3.200 = US:ER:3M:AC
          (users[1-n]) --- [linux1/router/fw] -- (net)
       This linux box would have a default (l3) route to the net.

  2. You could use two linux boxes.  The first (closest to the users)
      would have to do all of the layer 2 work - and then forward (bridge)
      traffic to the second.  The second would have to do ip NATing
      when matching the traffic from the MAC of the first ... I think ... I
      haven't done any layer 2 stuff in iptables.  Ie;
          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
      The second linux box has default (l3) route of the net, it would 
      reply to traffic from the outer interface mac address of the first
      linux box.


  Option 1 looks easy enough to do ... and seems cooler .. but option
2 might let you get away with doing this without writing a scrap of 
code ...  dunno ... check the kernel options and supporting software
for the layer 2 stuff .. and if iptables' match on mac will do what we
want then you're set.




----- Original Message -----
>From: "Ian Latter" <Ian.Latter@mq.edu.au>
>To: "Patrick McHardy" <kaber@trash.net>
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Fri, 14 Mar 2003 07:37:20 +1100
>
> Hmmm ....
> 
>   Yes .. you need to fix the laptops' routing ....  if we're not dhcp'ing all 
> of these people (which would be the first thing I'd do), then you're stuck
> with an internet's worth of IP addresses, masks and gateways ... from
> private to public.  So getting the traffic to your linux gateway is the first
> problem.   ie;
>    user1 = 10.1.1.99 / 255.255.0.0 - gw 10.10.0.12
>    user2 = 192.168.27.149 / 255.255.255.0 - gw 192.168.27.254
>    user3 = 1.2.3.200 / 255.0.0.0 - gw [not set]   (user3 has a www
>                                                                            server at 1.1.1.1)
> 
>   What you probably want to do is a layer2 fudge ... where, whatever
> they arp for, you give them the linux box; this will then sort out all of
> your routing issues ... ie;
>   user1 = arp for 10.10.0.12 ... ans = LI:NU:XM:AC
>   user2 = arp for 192.168.27.254 ... ans = LI:NU:XM:AC
>   user3 = arp for 1.1.1.1 .... ans = LI:NU:XM:AC
> 
> 
>   Once they're at the linux router/firewall doohicky, they can then
> be universally NAT the traffic .... but then you've got a problem ... 
> because the linux box, doing routing, will send user data back to
> the internet.  You can fix this by doing one of two things;
>   1.  Whatever does the arp spoofing to correct the routing, should
>        also rarp the ips of the macs currently asking for arps.  This
>        would allow you to layer2 correct the linux box.  this box would
>        have a default route to the net.
> 
>   2. You could use two linux boxes.  The first (closest to the users)
>       would have to do all of the layer 2 work - and then forward (bridge)
>       traffic to the second.  The second would have to do ip NATing
>       when matching the from MAC ... I think ... I haven't done any layer 2
>       stuff in iptables.  second box has default route of the net.
> 
> Go with 1.
> 
> One problem you'll have with the layer 2 spoofing is that one day the
> guy with www.intel.com on his laptop may arrive ... and he may choose
> to respond to his own arp requests ... as unlikely as this at first may
> appear to be  ... I'm sure its something that will bite you in the ass when
> you least want it to (on reflection, if he did arrive and did respond to his
> own arps, then you'll be the only guy in the world with the correct 
> routing ;-))
> 
> Honestly though ... your best bet is DHCP ... most people expect it .. and
> a lot of corporate networks are configured for it (meaning that the lappy
> owners don't have to change their config to plug into you).
> 
> If you do find a way to do the arp and rarp work properly, then let me 
> know ... I'd like to keep that one in my repetuar ...
> 
> 
> 
> ----- Original Message -----
> >From: "Patrick McHardy" <kaber@trash.net>
> >To: 
> >Subject:  Re: Transparent broadband network connectivity (IP PnP)
> >Date: Thu, 13 Mar 2003 20:19:16 +0100
> >
> > >
> > >
> > >>>Date: Thu, 13 Mar 2003 09:43:50 +0700
> > >>>To: laforge@gnumonks.org
> > >>>From: dragon_nlt@yahoo.com
> > >>>Subject: RE: Transparent broadband network connectivity (IP PnP)
> > >>>
> > >>>Hi,
> > >>>
> > >>>Maybe you will misunderstand my question. So i will describe the problem
> > >>>in detail.
> > >>>
> > >>>This is the implementation for such a public internet access network like
> > >>>airport, hotel, ... So the client IP address can be any thing. The main
> > >>>point is that a client just only need to plug into the net then he can
> > >>>surf internet without changing his ip configuration.
> > >>>I found some commercial products for this such as IP PnP
> > >>>(http://www.infino.co.kr/infino/eng/softpackage_e.php), Reliaware
> > >>>(http://www.demarctech.com/products/reliawave-rwh/reliawave-ipnpsg.html)
> > >>>(Please see Address Translate Function section). I wonder that iptables
> > >>>itself can do it or not.
> > >>>
> > >>>With iptables, we can nat outgoing traffic, but the problem is that
> > >>>clients inside internal network can be any IP address (different subnet,
> > >>>netmask, gateway, dns ... and even thought clients have the same IP). I
> > >>>think there is needed a layer-2 NAT, e.g. handling clients which may have
> > >>>any IP address (even the same IP address), etc. correctly. I found a
> > >>>useful thread here
> > >>>http://lists.personaltelco.net/pipermail/ptp/2002q4/010591.html.
> > >>>
> > >>>For example
> > >>>
> > >>>Client 1 -----------|
> > >>>192.168.10.5        |
> > >>>                    |  172.16.1.1  PublicIP
> > >>>Client 2 -----------|        eth0    eth1
> > >>>DHCP(172.16.1.90)   |-------- [ GW ] ----- [ router ] --- Internet
> > >>>                    |  DefaultGW=RouterIP
> > >>>Client 3 -----------|
> > >>>200.192.16.10       |
> > >>>                    |
> > >>>Client 4 -----------|
> > >>>64.12.5.12
> > >>>
> > >>>I can set the eth0 into proxy arp mode (net.ipv4.conf.eth0.proxy_arp = 1)
> > >>>to set it as the gateway for all clients, and use iptables SNAT target
> > >>>inside nat POSTROUTING chain of eth1.
> > >>>
> > >>>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source <eth1 ip>
> > >>>
> > >>>When client send a packet out, the packet goes into eth0, goes through
> > >>>forward chain after routing decision, get nat'd on eth1 then send to the
> > >>>router. The problem is that when the reply packet from router goes back
> > >>>eth1, after de-nat'd, the packet will be sent to the eth1 following the
> > >>>default route on gateway box instead of eth0 (since client can have any
> > >>>ip, so we can't set the routing table; default gateway is router's ip via
> > >>>eth1). I think there is needed such a MAC based NAT module on PREROUTING
> > >>>chain of eth0. So the gateway will don't care about client IP, just client
> > >>>MAC address (assume that MAC address is unique). Do you have any idea?
> > >>>
> > >>>Best Regards,
> > >>>
> > >>>John Duke
> > >>>      
> > >>>
> > 
> > I guess you could use conntrack match with --orig-dst and ROUTE target 
> > to force packets
> > out the "correct" interface. You probably still need to do some things 
> > to make linux send
> > arp requests for these ips.
> > 
> > Patrick
> > 
> > 
> > 
> > 
> 
> --
> Ian Latter
> Internet and Networking Security Officer
> Macquarie University
> 
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: Transparent broadband network connectivity (IP PnP)

[Patrick McHardy]

I still think my suggestion is a lot easier, as i understood him he already
got so far that the clients can send packet to the internet, they are SNATed
and reply packet reach the NAT box which DNATs them back automatically.
With a simple iptables rule packet can be directed to the client-network:
iptables -A PREROUTING -i eth1 -m conntrack --orig-dst <eth0-ip> -j 
ROUTE --oif eth1
Only thing left to do is make linux send arp requests for the client ips 
on eth1,
im unsure how this can be achieved or if anything needs to be done at all.

Patrick


Ian Latter wrote:

>Clarifying this ...  correcting 1 and 2 below;
>
>  Once they're at the linux router/firewall doohicky, they can then
>be universally NATed .... but then you've got a problem ... because
>the linux box, doing layer-3 routing, will send user data back to the
>internet.  You can fix this by doing one of two things;
>
>  1.  Whatever does the arp spoofing to correct the routing, should
>       also rarp the ips of the macs currently asking for arps.  This
>       would allow you to layer-2 correct/align the linux box.  ie;
>            rarp on 10.1.1.99 = US:ER:1M:AC
>            rarp on 192.168.27.149 = US:ER:2M:AC
>            rarp on 1.2.3.200 = US:ER:3M:AC
>          (users[1-n]) --- [linux1/router/fw] -- (net)
>       This linux box would have a default (l3) route to the net.
>
>  2. You could use two linux boxes.  The first (closest to the users)
>      would have to do all of the layer 2 work - and then forward (bridge)
>      traffic to the second.  The second would have to do ip NATing
>      when matching the traffic from the MAC of the first ... I think ... I
>      haven't done any layer 2 stuff in iptables.  Ie;
>          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
>      The second linux box has default (l3) route of the net, it would 
>      reply to traffic from the outer interface mac address of the first
>      linux box.
>
>
>  Option 1 looks easy enough to do ... and seems cooler .. but option
>2 might let you get away with doing this without writing a scrap of 
>code ...  dunno ... check the kernel options and supporting software
>for the layer 2 stuff .. and if iptables' match on mac will do what we
>want then you're set.
>
>
>
>  
>

Re: Transparent broadband network connectivity (IP PnP)

[John Duke]

Hi,

I'm realy reach the target with proxy arp and the following rules

                        172.16.1.1  PublicIP
Client 1 -----------|        eth0    eth1
<any IP>         |-------- [ GW ] ----- [ router ] --- Internet
                      |  DefaultGW=RouterIP
Client 2 -----------|
<any IP>

# snat output
(1) iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to <PublicIP>

# redirect de-nat'd return packet to internal network
(2) iptables -t mangle -A FORWARD -i eth1 -j ROUTE --iface eth0

# allow internal clients connect to 172.168.1.1 (for ssh, web, ...)
(3) iptables -t mangle -A POSTROUTING -o eth1 -m conntrack --ctreplsrc
172.16.1.1 -j ROUTE --iface eth0

With above configuration, client inside internal network (must use a valid
DNS server) can access into internet as well as connect to the gateway box
via ip 172.16.1.1

But in case client can have any ip configuration, I have to solve the
following issues:
         - Any ip (solved)
         - Any gateway (solved)
         - Any DNS setting (?)
         - Any proxy setting (?)

To solve the any DNS setting issue, I added DNS redirect as follow:

(4) iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to
<Public DNS IPs>
(5) iptables -t nat -I PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to
<Public DNS IPs>

Then the wierd thing happened. When client send a DNS request, the replied
SYN/ACK from Public DNS server to gateway box, after go into eth1
interface, seems to be disappeared in the kernel. I can not see either that
SYN/ACK packet send out to internal network via eth0 (in correct routing
case) or outside network via eth1 (in wrong routing case). For sure that if
i remove (2) rule, I can see the SYN/ACK packet after de-nat'd send out
again to eth1. It seems to me that ROUTE target has some weird side effect.
Do anyone have any suggestion to override DNS and proxy issues?

Regards,

John

At 12:32 AM 3/14/2003 +0100, Patrick McHardy wrote:
>I still think my suggestion is a lot easier, as i understood him he already
>got so far that the clients can send packet to the internet, they are SNATed
>and reply packet reach the NAT box which DNATs them back automatically.
>With a simple iptables rule packet can be directed to the client-network:
>iptables -A PREROUTING -i eth1 -m conntrack --orig-dst <eth0-ip> -j ROUTE
>--oif eth1
>Only thing left to do is make linux send arp requests for the client ips
>on eth1,
>im unsure how this can be achieved or if anything needs to be done at all.
>
>Patrick
>
>
>Ian Latter wrote:
>
>>Clarifying this ...  correcting 1 and 2 below;
>>
>>  Once they're at the linux router/firewall doohicky, they can then
>>be universally NATed .... but then you've got a problem ... because
>>the linux box, doing layer-3 routing, will send user data back to the
>>internet.  You can fix this by doing one of two things;
>>
>>  1.  Whatever does the arp spoofing to correct the routing, should
>>       also rarp the ips of the macs currently asking for arps.  This
>>       would allow you to layer-2 correct/align the linux box.  ie;
>>            rarp on 10.1.1.99 = US:ER:1M:AC
>>            rarp on 192.168.27.149 = US:ER:2M:AC
>>            rarp on 1.2.3.200 = US:ER:3M:AC
>>          (users[1-n]) --- [linux1/router/fw] -- (net)
>>       This linux box would have a default (l3) route to the net.
>>
>>  2. You could use two linux boxes.  The first (closest to the users)
>>      would have to do all of the layer 2 work - and then forward (bridge)
>>      traffic to the second.  The second would have to do ip NATing
>>      when matching the traffic from the MAC of the first ... I think ... I
>>      haven't done any layer 2 stuff in iptables.  Ie;
>>          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
>>      The second linux box has default (l3) route of the net, it
>> would      reply to traffic from the outer interface mac address of the first
>>      linux box.
>>
>>
>>  Option 1 looks easy enough to do ... and seems cooler .. but option
>>2 might let you get away with doing this without writing a scrap of code
>>...  dunno ... check the kernel options and supporting software
>>for the layer 2 stuff .. and if iptables' match on mac will do what we
>>want then you're set.
>>
>>
>>
>>
>

Re: Transparent broadband network connectivity (IP PnP)

[Cedric de Launois]

> Then the wierd thing happened. When client send a DNS request, the replied
> SYN/ACK from Public DNS server to gateway box, after go into eth1
> interface, seems to be disappeared in the kernel. I can not see either that
> SYN/ACK packet send out to internal network via eth0 (in correct routing
> case) or outside network via eth1 (in wrong routing case). For sure that if
> i remove (2) rule, I can see the SYN/ACK packet after de-nat'd send out
> again to eth1. It seems to me that ROUTE target has some weird side effect.

Could you please use the latest CVS version and activate the debug mode
for the ROUTE patch ? Just replace in file ipt_ROUTE.c, line 23 :
   #if 0
with 
   #if 1
to activate the debug mode.

You'll be able to see in the kernel logs why the ROUTE target drops the
packets.

I suspect packets are dropped because it can't guess the right hardware
address for your client. It will probably need a fix.

Cédric

Re: Transparent broadband network connectivity (IP PnP)

[Ian Latter]

Yeah, the proxy arp stuff is already built to do this sort of
thing;   http://lartc.org/howto/lartc.bridging.proxy-arp.html

.. I don't know if this gives us routing table entries for the
rarp'd addresses tho ... but if you're saying he doesn't
get the replies going back to those machines, then I guess
it doesn't ...  your rule may work depending on what that
proxy arp stuff does to the kernel routing table ...

We're keen to test it here .. we might have a crack at it
to see what it takes to get it working.





----- Original Message -----
>From: "Patrick McHardy" <kaber@trash.net>
>To: "Ian Latter" <Ian.Latter@mq.edu.au>
>Subject:  Re: Transparent broadband network connectivity (IP PnP)
>Date: Fri, 14 Mar 2003 00:32:56 +0100
>
> I still think my suggestion is a lot easier, as i understood him he already
> got so far that the clients can send packet to the internet, they are SNATed
> and reply packet reach the NAT box which DNATs them back automatically.
> With a simple iptables rule packet can be directed to the client-network:
> iptables -A PREROUTING -i eth1 -m conntrack --orig-dst <eth0-ip> -j 
> ROUTE --oif eth1
> Only thing left to do is make linux send arp requests for the client ips 
> on eth1,
> im unsure how this can be achieved or if anything needs to be done at all.
> 
> Patrick
> 
> 
> Ian Latter wrote:
> 
> >Clarifying this ...  correcting 1 and 2 below;
> >
> >  Once they're at the linux router/firewall doohicky, they can then
> >be universally NATed .... but then you've got a problem ... because
> >the linux box, doing layer-3 routing, will send user data back to the
> >internet.  You can fix this by doing one of two things;
> >
> >  1.  Whatever does the arp spoofing to correct the routing, should
> >       also rarp the ips of the macs currently asking for arps.  This
> >       would allow you to layer-2 correct/align the linux box.  ie;
> >            rarp on 10.1.1.99 = US:ER:1M:AC
> >            rarp on 192.168.27.149 = US:ER:2M:AC
> >            rarp on 1.2.3.200 = US:ER:3M:AC
> >          (users[1-n]) --- [linux1/router/fw] -- (net)
> >       This linux box would have a default (l3) route to the net.
> >
> >  2. You could use two linux boxes.  The first (closest to the users)
> >      would have to do all of the layer 2 work - and then forward (bridge)
> >      traffic to the second.  The second would have to do ip NATing
> >      when matching the traffic from the MAC of the first ... I think ... I
> >      haven't done any layer 2 stuff in iptables.  Ie;
> >          (users[1-n]) --- [linux1/l2bridge] -x- [linux2/router/fw] -- (net)
> >      The second linux box has default (l3) route of the net, it would 
> >      reply to traffic from the outer interface mac address of the first
> >      linux box.
> >
> >
> >  Option 1 looks easy enough to do ... and seems cooler .. but option
> >2 might let you get away with doing this without writing a scrap of 
> >code ...  dunno ... check the kernel options and supporting software
> >for the layer 2 stuff .. and if iptables' match on mac will do what we
> >want then you're set.
> >
> >
> >
> >  
> >
> 
> 
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University