Bridge between interfaces without snat??

From: Mark Richards (mark.nospam.richards_at_massmicro.com)
Date: 07/30/04


Date: Fri, 30 Jul 2004 19:51:19 GMT

I am struggling with a real beast :)

My attempts at getting a simple nat (snat) iptables implementation to work is failing.

My setup:

Server (AXIS 82 Development platform running kernel 2.4.26 and iptables 1.2.7a)

eth0 Link encap:Ethernet HWaddr 00:40:8C:63:10:A0
          inet addr:192.168.1.90 Bcast:192.168.255.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:1596 errors:0 dropped:0 overruns:0 frame:1
          TX packets:655 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:107253 (104.7 kiB) TX bytes:88628 (86.5 kiB)
          Interrupt:17 DMA chan:1

eth0 is connected to the local lan (192.168.1.1) which is a linksys router.

eth1 Link encap:Ethernet HWaddr 00:40:8C:63:10:A1
          inet addr:192.168.0.90 Bcast:192.168.255.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:61 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7200 (7.0 kiB) TX bytes:3070 (2.9 kiB)

eth1 is connected to eth2 of a client :

Client (fedora 2 2.6.5 kernel)

eth1 Link encap:Ethernet HWaddr 00:50:BA:F7:A4:5F
          inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::250:baff:fef7:a45f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:17526 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7755 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7173794 (6.8 Mb) TX bytes:930848 (909.0 Kb)
          Interrupt:10 Base address:0x2400

eth2 Link encap:Ethernet HWaddr 00:E0:29:3E:63:22
          inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0
          inet6 addr: fe80::2e0:29ff:fe3e:6322/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:9264 errors:0 dropped:0 overruns:0 frame:0
          TX packets:301 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:680334 (664.3 Kb) TX bytes:35802 (34.9 Kb)
          Interrupt:11 Base address:0x2800

The client gets its eth2 i/p address from a udhcpd daemon running on the server.
The ip address is received without any issue or error message (dmesg and messages indicate no errors)

However... when I start udhcpd (the AXIS dhcp server) I see in ./var/log/messages:

Jul 30 14:19:06 AxisProduct udhcpd: udhcp server (v0.9.8) started
Jul 30 14:19:06 AxisProduct udhcpd: SIOCGIFADDR failed, is the interface up and configured?: Cannot assign requested address
Jul 30 14:19:21 AxisProduct udhcpd: udhcp server (v0.9.8) started
Jul 30 14:20:30 AxisProduct udhcpd: sending OFFER of 192.168.0.20
Jul 30 14:20:30 AxisProduct udhcpd: sending ACK to 192.168.0.20

It appears that the client gets the ip (from eth1), but I am worried about that SIOCGIFADDR error.

I don't have a default gateway set for eth1. Should I? If so, what should it be set to? eth0's default gateway is the router I use for the internal LAN, which is at 192.168.1.1

The client does not have any iptables filtering enabled and I made certain of it by running a script that clears everything. It looks like this:

/sbin/iptables -t nat -L
        Chain PREROUTING (policy ACCEPT)
        target prot opt source destination
        
        Chain POSTROUTING (policy ACCEPT)
        target prot opt source destination

        Chain OUTPUT (policy ACCEPT)
        target prot opt source destination

On the server, I also make sure to clear the iptables out. With NO routing, I find that I am able to ping the axis's eth0 address (192.168.1.90) from the client side:
        ping -c 2 192.168.1.90 -I eth2

And I get packets back just fine!! Is this possible? Since I have NOT set up any routing (yet) on the server, why does a ping get through??

Here's the iptables command I am issuing to establish snat on the AXIS 82:

        iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.1.90
        echo 1 > /proc/sys/net/ipv4/ip_forward

Here's what iptables -t nat -L says:

        Chain PREROUTING (policy ACCEPT)
        target prot opt source destination

        Chain POSTROUTING (policy ACCEPT)
        target prot opt source destination
        SNAT all -- anywhere anywhere to:192.168.1.80
        SNAT all -- anywhere anywhere to:192.168.1.90

        Chain OUTPUT (policy ACCEPT)
        target prot opt source destination

With my iptables command set as above, any attempt to ping outside the AXIS's eth0 adapter fails with "destination host unreachable".

Here's the client routing table:

/sbin/route
        Kernel IP routing table
        Destination Gateway Genmask Flags Metric Ref Use Iface
        192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
        192.168.0.0 * 255.255.255.0 U 0 0 0 eth2
        169.254.0.0 * 255.255.0.0 U 0 0 0 eth1

And here's the AXIS 82 routing table:

        Kernel IP routing table
        Destination Gateway Genmask Flags Metric Ref Use Iface
        192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
        192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
        default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

It seems to me that with the above iptables command (with the thing wide open) I should easily get through, and that I should *not* get through to eth0 (from a client connected on eth2 on a different subnet) when I have no snat loaded!

Any ideas out there?

Mark Richards



Relevant Pages

  • Re: IPTables Port Forwarding
    ... ESTABLISHED and RELATED connections: ... packets will go back through your firewall). ... Then the client gets an answer from "192.168.1.50", ... iptables -t nat -F ...
    (Debian-User)
  • Re: one routing question
    ... Using the route command I can´t make this routing, perhaps I can do it using ... You use your RH machine an an HTTP client to browse other remote ... IPTables doesn't get involved at all. ... upstream next-hop, so that any traffic you originate leaves via eth1, ...
    (RedHat)
  • Re: iptables: Redirect/Forward any traffic based on MAC address
    ... To catch http attempts from not yet authorized computers ... > you didnt finish your sentence, but I guess you then want iptables to let ... time out authorized client computers after some number ...
    (comp.os.linux.security)
  • Re: Allgemein: netfilter, routing, sonstige flags
    ... > ich habe zwar mit iptables einige Paketfilter konfiguriert. ... Mit Routen legst du dagegen fest, dass Pakete, die auf einer ... Bei einfachem Routing kannst du nur die Ziel-IP-Adressen zur ... die sich von Netzwerkschnittstelle zu ...
    (de.comp.os.unix.networking.misc)
  • policy-based routing and NAT with iptables
    ... I try to setup policy-based routing under linux with iptables and ip ... configured iptables so that packets with some port-numbers are marked. ... Those packets marked should receive the second routing-table. ... hostname:/home/airflow# ip route list table default ...
    (comp.os.linux.networking)