NAT from ethernet to bridge, is it possible?

oTarUX · 2011-02-23 09:36:37

Hi, I've managed to set up a softap or sort of using hostapd. Basically what i'm trying to do is to share my internet connection from the usb modem to a bridge (wireless and ethernet). Everything's wonrking but the sharing part, people can connect to the bridge, get and ip from dnsmasq and that's all so far. Tried to follow a few guides but couldn't do it. So, I've tried the ubuntu way, installed firestarter, followed the wizard and it worked. I must be missing some iptables rules or something 'cause I don't know anything about iptables.
This is the closest thing that I've seen to what I'm trying to acomplish.
http://ebtables.sourceforge.net/br_fw_i … l#section7
Only difference is that there's a wireless card in my bridge set up, but as I said before, bridge is working great (sharing files and lan gaming), it just can't reach internet.
Followed some tutorials and scripts but no results.
Example from above

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

Some other example

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i br0 -j ACCEPT
iptables -A FORWARD -i eth1 -o br0 -j ACCEPT
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT

This page i've used it for ages but didn't work this time.
http://easyfwgen.morizot.net/gen/
Some of my config files:
/etc/rc.conf

eth1="dhcp"
wlan0="wlan0 up"
eth0="eth0 up"
br0="br0 192.168.0.1 netmask 255.255.255.0 up"
INTERFACES=(eth1 wlan0 eth0 br0)

/etc/conf.d/bridges

bridge_br0="wlan0 eth0"
BRIDGE_INTERFACES=(br0)

I should read some documentation about iptables, but at least i've tried not to post until I've tried to run out of knowledge (or google results in this case). Thanks in advance.

fukawi2 · 2011-02-23 12:30:58

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT

That should work.... With those in place, and after you do some testing, what is the output of these commands:

iptables -nvL
iptables -t nat -nvL

oTarUX · 2011-02-23 12:57:15

Thanks a lot for the quick answer, but it's still not workin'. With your rules I can ping everywhere but that's all, no surfing. Browser says waiting for reply... and stays that way. I've tried changing dns but i don't thing it's related to that, it's like packets can't find they way back to the bridge or something. Thanks again.
iptables -nvL (with iptables flushed)

Chain INPUT (policy ACCEPT 9 packets, 1904 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 279 packets, 60232 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 3 packets, 308 bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -t nat -nvL (with iptables flushed)

Chain PREROUTING (policy ACCEPT 18 packets, 4796 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 4 packets, 225 bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -nvL (with your rules)

Chain INPUT (policy ACCEPT 135 packets, 15878 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 292 packets, 74604 bytes)
 pkts bytes target     prot opt in     out     source               destination 
  531  104K ACCEPT     all  --  br0    eth1    0.0.0.0/0            0.0.0.0/0   

Chain OUTPUT (policy ACCEPT 127 packets, 20294 bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -t nat -nvL (with your rules)

Chain PREROUTING (policy ACCEPT 21 packets, 2276 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain INPUT (policy ACCEPT 5 packets, 1122 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 5 packets, 363 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 1 packets, 235 bytes)
 pkts bytes target     prot opt in     out     source               destination 
   14  1090 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0

fukawi2 · 2011-02-23 22:47:16

Weird... And you say ping works? eg, ping google.com?

If that works, then the rules and DNS are correct.

Try running `tcpdump -lnn -i eth1 port 80 and tcp-syn` when trying to open a webpage, and post the output for us.

oTarUX · 2011-02-23 23:44:07

Pinging works, not only for google. Tried it with yahoo.com, live.com and theres not a packed loss.
ping google.com

PING google.com (209.85.195.104) 56(84) bytes of data.
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=1 ttl=53 time=16.2 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=2 ttl=53 time=16.4 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=3 ttl=53 time=10.1 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=4 ttl=53 time=14.4 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=5 ttl=53 time=10.0 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=6 ttl=53 time=14.4 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=7 ttl=53 time=42.4 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=8 ttl=53 time=31.4 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=9 ttl=53 time=29.0 ms
64 bytes from eze03s01-in-f104.1e100.net (209.85.195.104): icmp_req=10 ttl=53 time=35.4 ms
^C
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 10.075/22.014/42.457/10.950 ms

Then I've runned

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT

tcpdump -lnn -i eth1 port 80 and tcp-syn

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:32:14.612265 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [s], seq 1195182321, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:32:14.612282 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [s], seq 1195182321, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:32:14.612292 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [s], seq 1195182321, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:32:14.642900 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [S.], seq 3556826970, ack 1195182322, win 5720, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0
20:32:14.642891 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [S.], seq 3556826970, ack 1195182322, win 5720, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0
20:32:14.642877 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [S.], seq 3556826970, ack 1195182322, win 5720, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0
20:32:14.646620 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], ack 1, win 4290, length 0
20:32:14.646604 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], ack 1, win 4290, length 0
20:32:14.646631 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], ack 1, win 4290, length 0
20:32:14.959133 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], seq 1:533, ack 1, win 4290, length 532
20:32:14.959260 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [P.], seq 557:948, ack 1, win 4290, length 391
20:32:14.959144 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], seq 1:533, ack 1, win 4290, length 532
20:32:14.959266 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [P.], seq 557:948, ack 1, win 4290, length 391
20:32:14.959108 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [.], seq 1:533, ack 1, win 4290, length 532
20:32:14.959254 IP 186.137.233.12.54362 > 209.85.195.83.80: Flags [P.], seq 557:948, ack 1, win 4290, length 391
20:32:14.986826 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 557, win 107, length 0
20:32:14.986806 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 557, win 107, length 0
20:32:14.986819 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 557, win 107, length 0
20:32:14.987857 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 948, win 125, length 0
20:32:14.987845 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 948, win 125, length 0
20:32:14.987862 IP 209.85.195.83.80 > 186.137.233.12.54362: Flags [.], ack 948, win 125, length 0
20:33:07.002619 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [F.], seq 6045, ack 20433, win 4068, length 0
20:33:07.002594 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [F.], seq 2015, ack 6811, win 4068, length 0
20:33:07.002612 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [F.], seq 4030, ack 13621, win 4068, length 0
20:33:07.017321 IP 209.85.195.104.80 > 186.137.233.12.54356: Flags [F.], seq 6811, ack 2016, win 391, length 0
20:33:07.017338 IP 209.85.195.104.80 > 186.137.233.12.54356: Flags [F.], seq 13621, ack 4031, win 391, length 0
20:33:07.017347 IP 209.85.195.104.80 > 186.137.233.12.54356: Flags [F.], seq 20433, ack 6046, win 391, length 0
20:33:07.019004 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [.], ack 13622, win 4068, length 0
20:33:07.019010 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [.], ack 20434, win 4068, length 0
20:33:07.018990 IP 186.137.233.12.54356 > 209.85.195.104.80: Flags [.], ack 6812, win 4068, length 0

Just tell me if you need longert output, thanks.

Last edited by oTarUX (2011-02-23 23:44:24)

fukawi2 · 2011-02-24 03:52:32

This shows that it is working...
186.137.233.12.54362 > 209.85.195.83.80
The traffic is going out eth1 (your internet connection) to 209.85.195.83 (a Google data center address). It is being SNAT'ed to your public IP 186.137.233.12 (I presume this is the address assigned to eth1 unless something is REALLY weird).

I don't think your problem is anything to do with iptables snat and/or bridging.

One last test to be sure, install tcptraceroute (AUR: http://aur.archlinux.org/packages.php?ID=43543) and run this from your client (not the server with the bridge etc):

tcptraceroute google.com 80

oTarUX · 2011-02-24 07:11:11

Yes, 186.137.233.12 is the modem's ip. I don't know what the problem is, but in the client pages never time out, browser keeps waiting forever. I can post the output of theses command but when everithing's working right so you'll see what firestarter it's doing.
tcptraceroute google.com 80 (client)

Selected device wlan0, address 192.168.0.62, port 47710 for outgoing packets
Tracing the path to google.com (209.85.195.104) on TCP port 80 (http), 30 hops max
 1  192.168.0.1  1.310 ms  0.777 ms  0.769 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  133-165-89-200.fibertel.com.ar (200.89.165.133)  12.289 ms  10.352 ms  12.941 ms
 7  130-165-89-200.fibertel.com.ar (200.89.165.130)  12.871 ms  29.647 ms  12.868 ms
 8  * * *
 9  * * *
10  200.49.159.254  61.394 ms  13.099 ms  14.917 ms
11  209.85.251.28  17.915 ms  32.839 ms  15.883 ms
12  209.85.251.6  15.911 ms  37.038 ms  17.885 ms
13  * * *
14  * * *
15  eze03s01-in-f104.1e100.net (209.85.195.104) [open]  13.778 ms  32.436 ms  18.251 ms

Last edited by oTarUX (2011-02-24 07:11:43)

cactus · 2011-02-24 10:22:29

I think you need to let traffic back in now?

iptables -A FORWARD -i eth1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Maybe start with this?

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE

edit: actually, you had forward accept before, so it should have worked. weird.
did you have ip_forward set?

Last edited by cactus (2011-02-24 10:32:18)

oTarUX · 2011-02-24 11:00:35

cactus wrote:

I think you need to let traffic back in now?

iptables -A FORWARD -i eth1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Maybe start with this?

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE

edit: actually, you had forward accept before, so it should have worked. weird.
did you have ip_forward set?

I've set it up in /etc/sysctl.conf

# Disable packet forwarding
net.ipv4.ip_forward=1

It's still not working, these are new outputs.
iptables -nvL (server)

Chain INPUT (policy ACCEPT 161 packets, 16792 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
   76 15782 ACCEPT     all  --  br0    eth1    0.0.0.0/0            0.0.0.0/0   
   46 11318 ACCEPT     all  --  eth1   br0     0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 114 packets, 16681 bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -t nat -nvL (server)

Chain PREROUTING (policy ACCEPT 3 packets, 443 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain INPUT (policy ACCEPT 2 packets, 391 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 4 packets, 252 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 4 packets, 252 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    1    52 MASQUERADE  all  --  *      eth1    192.168.0.0/24       0.0.0.0/0

tcptraceroute google.com 80 (client)

Selected device wlan0, address 192.168.0.62, port 53837 for outgoing packets
Tracing the path to google.com (209.85.195.104) on TCP port 80 (http), 30 hops max
 1  192.168.0.1  0.979 ms  0.773 ms  0.816 ms
 2  1-233-137-186.fibertel.com.ar (186.137.233.1)  2927.695 ms  2249.790 ms  1408.991 ms
 3  * * *
 4  * * *
 5  * * *
 6  137-165-89-200.fibertel.com.ar (200.89.165.137)  12.823 ms  13.232 ms  14.878 ms
 7  130-165-89-200.fibertel.com.ar (200.89.165.130)  39.884 ms  12.638 ms  14.225 ms
 8  * * *
 9  * * *
10  200.49.159.254  36.514 ms  29.952 ms  11.863 ms
11  209.85.251.28  12.899 ms  57.390 ms  12.889 ms
12  209.85.251.6  12.921 ms  25.877 ms  17.502 ms
13  * * *
14  * * *
15  eze03s01-in-f104.1e100.net (209.85.195.104) [open]  16.140 ms  14.286 ms  28.733 ms

Last edited by oTarUX (2011-02-24 11:58:07)

fukawi2 · 2011-02-24 11:29:05

oTarUX wrote:

I can post the output of theses command but when everithing's working right so you'll see what firestarter it's doing.
tcptraceroute google.com 80 (client)

Selected device wlan0, address 192.168.0.62, port 47710 for outgoing packets
Tracing the path to google.com (209.85.195.104) on TCP port 80 (http), 30 hops max
 1  192.168.0.1  1.310 ms  0.777 ms  0.769 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  133-165-89-200.fibertel.com.ar (200.89.165.133)  12.289 ms  10.352 ms  12.941 ms
 7  130-165-89-200.fibertel.com.ar (200.89.165.130)  12.871 ms  29.647 ms  12.868 ms
 8  * * *
 9  * * *
10  200.49.159.254  61.394 ms  13.099 ms  14.917 ms
11  209.85.251.28  17.915 ms  32.839 ms  15.883 ms
12  209.85.251.6  15.911 ms  37.038 ms  17.885 ms
13  * * *
14  * * *
15  eze03s01-in-f104.1e100.net (209.85.195.104) [open]  13.778 ms  32.436 ms  18.251 ms

Do you get that same (or very similar) output when things are 'broken'?

oTarUX · 2011-02-24 12:04:05

fukawi2 wrote:

oTarUX wrote:

I can post the output of theses command but when everithing's working right so you'll see what firestarter it's doing.
tcptraceroute google.com 80 (client)

Selected device wlan0, address 192.168.0.62, port 47710 for outgoing packets
Tracing the path to google.com (209.85.195.104) on TCP port 80 (http), 30 hops max
 1  192.168.0.1  1.310 ms  0.777 ms  0.769 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  133-165-89-200.fibertel.com.ar (200.89.165.133)  12.289 ms  10.352 ms  12.941 ms
 7  130-165-89-200.fibertel.com.ar (200.89.165.130)  12.871 ms  29.647 ms  12.868 ms
 8  * * *
 9  * * *
10  200.49.159.254  61.394 ms  13.099 ms  14.917 ms
11  209.85.251.28  17.915 ms  32.839 ms  15.883 ms
12  209.85.251.6  15.911 ms  37.038 ms  17.885 ms
13  * * *
14  * * *
15  eze03s01-in-f104.1e100.net (209.85.195.104) [open]  13.778 ms  32.436 ms  18.251 ms

Do you get that same (or very similar) output when things are 'broken'?

Here it is:
tcptraceroute google.com 80 (client)

Selected device wlan0, address 192.168.0.62, port 37660 for outgoing packets
Tracing the path to google.com (209.85.195.104) on TCP port 80 (http), 30 hops max
 1  192.168.0.1  1.273 ms  0.770 ms  0.751 ms
 2  1-233-137-186.fibertel.com.ar (186.137.233.1)  267.267 ms  202.066 ms  82.719 ms
 3  * * *
 4  * * *
 5  * * *
 6  165-165-89-200.fibertel.com.ar (200.89.165.165)  15.637 ms  14.826 ms  13.886 ms
 7  130-165-89-200.fibertel.com.ar (200.89.165.130)  11.921 ms  13.529 ms  28.868 ms
 8  * * *
 9  * * *
10  200.49.159.254  14.394 ms  12.422 ms  48.846 ms
11  209.85.251.28  24.910 ms  16.384 ms  27.862 ms
12  * 209.85.251.6 19.580 ms  28.743 ms
13  * * *
14  * * *
15  eze03s01-in-f104.1e100.net (209.85.195.104) [open]  15.355 ms  16.209 ms  12.733 ms

But iptables -nvL on the server (firestarter running) there are like a billon rules set, very long output.

fukawi2 · 2011-02-24 22:53:33

So tcptraceroute shows the same with and without firestarter?

oTarUX · 2011-02-25 01:17:32

fukawi2 wrote:

So tcptraceroute shows the same with and without firestarter?

It's not exactly the same, look at 2nd hop, it isn't relevant?

Last edited by oTarUX (2011-02-25 01:18:17)

fukawi2 · 2011-02-25 03:33:36

I don't think it should be relevant to this problem... The 2nd hop is passing the traffic through (since hop 3-15 come back) but it's just not responding with an icmp ttl-expired packet when it sees the traceroute packet with the 0 ttl value. The fact that it shows when you're not using firestarter, but doesn't show when you are, demonstrates that your firewall policies are actually more open (ie, less restrictive) when not using firestarter.

Either way, the TCP port 80 traffic passes through your gateway and is NAT'ed correctly in both instances.

Perhaps a kernel conn tracking issue...
1. Put your 'broken' rules in place.
2. Open http://www.ipchicken.com on your client browser.
3. Post the output of the following on your gateway:

grep 209.68.27.16 /proc/net/ip_conntrack

EDIT: You'll have to be fairly quick (<10 seconds or so probably) between 2 and 3 because the connection may expire fairly quickly.

Last edited by fukawi2 (2011-02-25 03:35:27)

oTarUX · 2011-02-25 03:46:12

I'll try that, but to add some more info (or mistery), if I'm using emesene with firestarter and then flush rules and add those 2 or 3 iptables rules, chat windows already open still work. That's odd like ping working, right?

fukawi2 wrote:

3. Post the output of the following on your gateway:
grep 209.68.27.16 /proc/net/ip_conntrack
EDIT: You'll have to be fairly quick (<10 seconds or so probably) between 2 and 3 because the connection may expire fairly quickly.

That will translate as "there's no space left in the device", wich is wrong.
df -h

S.ficheros          Tamaño Usado  Disp Uso% Montado en
udev                   10M   68K   10M   1% /dev
/dev/sda1             3,8G  1,4G  2,5G  36% /
shm                   124M     0  124M   0% /dev/shm

Maybe I've mised somethingin in the command above(?).

Last edited by oTarUX (2011-02-25 04:06:30)

fukawi2 · 2011-02-25 11:31:23

/proc won't show in df... Check `mount | grep proc`

I can't think of any way 'grep' could result in a 'no space on device' error.

oTarUX · 2011-02-25 12:18:37

fukawi2 wrote:

/proc won't show in df... Check `mount | grep proc`
I can't think of any way 'grep' could result in a 'no space on device' error.

Maybe some kernel related issue?
uname -a

Linux saberx 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 18 16:58:42 UTC 2011 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

mount | grep proc

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

cat /etc/fstab

# 
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
devpts /dev/ptsdevptsdefaults00
shm /dev/shm tmpfs nodev,nosuid00
/dev/sda1 / reiserfsdefaults 0 1
/dev/sda3 swapswap defaults 0 0

fukawi2 · 2011-02-26 00:16:29

oTarUX wrote:

mount | grep proc

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

OK, so /proc is there... Does that file (/proc/net/ip_conntrack) exist?

oTarUX · 2011-02-26 04:17:02

fukawi2 wrote:

oTarUX wrote:
mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
OK, so /proc is there... Does that file (/proc/net/ip_conntrack) exist?

Yes it does, but i can't "grep it" or "cat it", same error shows up. There's also a /proc/net/ip_conntrack_expect wich i can grep and cat, but it's empty.
ls -l /proc/net/ip_conntrack*
-r--r----- 1 root root 0 feb 26 01:17 /proc/net/ip_conntrack
-r--r----- 1 root root 0 feb 26 01:17 /proc/net/ip_conntrack_expect

fukawi2 · 2011-02-26 10:09:18

Ah, I knew it sounded familiar...
https://bbs.archlinux.org/viewtopic.php?id=113274

I'd downgrade your kernel until that issue can be resolved.

oTarUX · 2011-02-26 10:51:09

Thanks for the advice, I'll install the lts kernel and see what happerns.

oTarUX · 2011-02-26 12:08:20

fukawi2 wrote:

1. Put your 'broken' rules in place.
2. Open http://www.ipchicken.com on your client browser.
3. Post the output of the following on your gateway:
grep 209.68.27.16 /proc/net/ip_conntrack

1. ./test.sh

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A FORWARD -i br0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE

2. Done.
3. grep 209.68.27.16 /proc/net/ip_conntrack

tcp      6 431992 ESTABLISHED src=192.168.0.62 dst=209.68.27.16 sport=37496 dport=80 packets=5 bytes=1450 src=209.68.27.16 dst=186.137.233.12 sport=80 dport=37496 packets=3 bytes=168 [ASSURED] mark=0 secmark=0 use=2

Changing to:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

Same output.

tcp      6 431998 ESTABLISHED src=192.168.0.62 dst=209.68.27.16 sport=49226 dport=80 packets=4 bytes=807 src=209.68.27.16 dst=186.137.233.12 sport=80 dport=49226 packets=3 bytes=168 [ASSURED] mark=0 secmark=0 use=2

fukawi2 · 2011-02-26 22:04:23

But it still doesn't work...?

Very weird, I'm out of ideas, sorry

As a side note though, in your test.sh:
1. Since your Policy (-P) for all the filter chains is ACCEPT, you don't need to put the separate ACCEPT rules in.
2. You don't need the -s argument in the MASQUERADE rules, since you want to apply it to everything going out your internet connection (with -o)

fukawi2 · 2011-02-26 22:09:00

Actually, one more idea that might point us to the problem...

Add this to the end of test.sh

iptables -t filter -A INPUT -i eth1 -j LOG --log-prefix='[END OF INPUT] '
iptables -t filter -A OUTPUT -o eth1 -j LOG --log-prefix='[END OF OUTPUT] '
iptables -t filter -A FORWARD -j LOG --log-prefix='[END OF FORWARD] '
iptables -t nat -A POSTROUTING -i eth1 -j LOG --log-prefix='[END OF POSTROUTING in] '
iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix='[END OF POSTROUTING out] '

What are your policies in the 'nat' and 'mangle' tables?

iptables -t nat -nVL
iptables -t mangle -nVL

They should be ACCEPT, but we're running out of ideas...!

oTarUX · 2011-02-26 22:32:18

When I tried to run tets.sh it says "iptables v1.4.10: Can't use -i with POSTROUTING", something worng here?

iptables -t nat -A POSTROUTING -i eth1 -j LOG --log-prefix='[END OF POSTROUTING in] '

Arch Linux

#1 2011-02-23 09:36:37

NAT from ethernet to bridge, is it possible?

#2 2011-02-23 12:30:58

Re: NAT from ethernet to bridge, is it possible?

#3 2011-02-23 12:57:15

Re: NAT from ethernet to bridge, is it possible?

#4 2011-02-23 22:47:16

Re: NAT from ethernet to bridge, is it possible?

#5 2011-02-23 23:44:07

Re: NAT from ethernet to bridge, is it possible?

#6 2011-02-24 03:52:32

Re: NAT from ethernet to bridge, is it possible?

#7 2011-02-24 07:11:11

Re: NAT from ethernet to bridge, is it possible?

#8 2011-02-24 10:22:29

Re: NAT from ethernet to bridge, is it possible?

#9 2011-02-24 11:00:35

Re: NAT from ethernet to bridge, is it possible?

#10 2011-02-24 11:29:05

Re: NAT from ethernet to bridge, is it possible?

#11 2011-02-24 12:04:05

Re: NAT from ethernet to bridge, is it possible?

#12 2011-02-24 22:53:33

Re: NAT from ethernet to bridge, is it possible?

#13 2011-02-25 01:17:32

Re: NAT from ethernet to bridge, is it possible?

#14 2011-02-25 03:33:36

Re: NAT from ethernet to bridge, is it possible?

#15 2011-02-25 03:46:12

Re: NAT from ethernet to bridge, is it possible?

#16 2011-02-25 11:31:23

Re: NAT from ethernet to bridge, is it possible?

#17 2011-02-25 12:18:37

Re: NAT from ethernet to bridge, is it possible?

#18 2011-02-26 00:16:29

Re: NAT from ethernet to bridge, is it possible?

#19 2011-02-26 04:17:02

Re: NAT from ethernet to bridge, is it possible?

#20 2011-02-26 10:09:18

Re: NAT from ethernet to bridge, is it possible?

#21 2011-02-26 10:51:09

Re: NAT from ethernet to bridge, is it possible?

#22 2011-02-26 12:08:20

Re: NAT from ethernet to bridge, is it possible?

#23 2011-02-26 22:04:23

Re: NAT from ethernet to bridge, is it possible?

#24 2011-02-26 22:09:00

Re: NAT from ethernet to bridge, is it possible?

#25 2011-02-26 22:32:18

Re: NAT from ethernet to bridge, is it possible?

Board footer