USB Networking vs. iptables
Christian Weßel
wesselch at gmx.net
Fri Sep 19 08:36:58 CEST 2008
Hello,
first I correct the DNS address at the both DNATs at the server side:
[root at SVDL002 backup]# iptables -L -t nat --line-numbers -n -v
Chain PREROUTING (policy ACCEPT 2829 packets, 171K bytes)
num pkts bytes target prot opt in out source
destination
1 0 0 DNAT tcp -- * * 192.168.0.202
192.168.0.200 tcp dpt:53 to:212.6.108.140
2 20 1248 DNAT udp -- * * 192.168.0.202
192.168.0.200 udp dpt:53 to:212.6.108.140
Chain POSTROUTING (policy ACCEPT 9133 packets, 641K bytes)
num pkts bytes target prot opt in out source
destination
1 59 6086 MASQUERADE all -- * * 192.168.0.0/24
0.0.0.0/0
But I recognize no pos. At the FR I have still the same results:
root at om-gta02:~# cat /etc/resolv.conf
nameserver 192.168.0.200
root at om-gta02:~# nslookup www.google.com
Server: 192.168.0.200
Address 1: 192.168.0.200
nslookup: can't resolve 'www.google.com'
I checked the filter table, I see no mistake. The most are standard
rules by RH/FC. The input and the forward chains are affect no traffic,
except the listed IPs:22 in private chain 'RH-Firewall-1-INPUT'.
on server:
[root at SVDL002 backup]# iptables -L -t nat --line-numbers -n -v
Chain PREROUTING (policy ACCEPT 2812 packets, 170K bytes)
num pkts bytes target prot opt in out source
destination
1 0 0 DNAT tcp -- * * 192.168.0.202
192.168.0.200 tcp dpt:53 to:212.6.108.140
2 20 1248 DNAT udp -- * * 192.168.0.202
192.168.0.200 udp dpt:53 to:212.6.108.140
Chain POSTROUTING (policy ACCEPT 9082 packets, 638K bytes)
num pkts bytes target prot opt in out source
destination
1 59 6086 MASQUERADE all -- * * 192.168.0.0/24
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 9097 packets, 640K bytes)
num pkts bytes target prot opt in out source
destination
[root at SVDL002 backup]# iptables -L --line-numbers -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source
destination
1 592K 375M RH-Firewall-1-INPUT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source
destination
1 701 45828 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 613K packets, 261M bytes)
num pkts bytes target prot opt in out source
destination
Chain RH-Firewall-1-INPUT (2 references)
num pkts bytes target prot opt in out source
destination
1 18 1488 DROP tcp -- * * 200.148.247.20
0.0.0.0/0 tcp dpt:22
2 23 1256 DROP tcp -- * * 85.114.135.61
0.0.0.0/0 tcp dpt:22
3 19 1420 DROP tcp -- * * 82.117.193.162
0.0.0.0/0 tcp dpt:22
4 16 1292 DROP tcp -- * * 218.240.15.45
0.0.0.0/0 tcp dpt:22
5 19 1552 DROP tcp -- * * 219.143.219.129
0.0.0.0/0 tcp dpt:22
6 21 1668 DROP tcp -- * * 211.20.200.24
0.0.0.0/0 tcp dpt:22
7 23 1836 DROP tcp -- * * 64.152.73.79
0.0.0.0/0 tcp dpt:22
8 19 1500 DROP tcp -- * * 203.112.151.49
0.0.0.0/0 tcp dpt:22
9 2 120 DROP tcp -- * * 91.121.162.172
0.0.0.0/0 tcp dpt:22
10 22 1732 DROP tcp -- * * 211.157.110.226
0.0.0.0/0 tcp dpt:22
11 17 1356 DROP tcp -- * * 219.94.180.143
0.0.0.0/0 tcp dpt:22
12 16 1296 DROP tcp -- * * 200.196.51.29
0.0.0.0/0 tcp dpt:22
13 20 1536 DROP tcp -- * * 222.221.12.13
0.0.0.0/0 tcp dpt:22
14 20 2800 DROP tcp -- * * 194.165.132.66
0.0.0.0/0 tcp dpt:22
15 21 1668 DROP tcp -- * * 58.253.67.58
0.0.0.0/0 tcp dpt:22
16 17 3048 DROP tcp -- * * 91.112.122.242
0.0.0.0/0 tcp dpt:22
17 19 1840 DROP tcp -- * * 125.206.243.126
0.0.0.0/0 tcp dpt:22
18 0 0 DROP tcp -- * * 72.29.77.144
0.0.0.0/0 tcp dpt:22
19 20 1636 DROP tcp -- * * 59.42.177.139
0.0.0.0/0 tcp dpt:22
20 18 1316 DROP tcp -- * * 212.14.37.2
0.0.0.0/0 tcp dpt:22
21 246K 210M ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
22 898 78034 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 255
23 0 0 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
24 0 0 ACCEPT ah -- * * 0.0.0.0/0
0.0.0.0/0
25 72 20607 ACCEPT udp -- * * 0.0.0.0/0
224.0.0.251 udp dpt:5353
26 0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:631
27 0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:631
28 330K 164M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
29 180 10764 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:22
30 0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:443
31 4155 244K ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:80
32 9849 611K REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
Due to the masquerade I checked, if it would helpful to change the
FR.resolv.conf to the same DNS (212.6.108.140), but I got just the known
result:
root at om-gta02:~# nslookup www.google.com
Server: 212.6.108.140
Address 1: 212.6.108.140
nslookup: can't resolve 'www.google.com'
If I ping from FR to this IP I got a good result:
root at om-gta02:~# ping 212.6.108.140
PING 212.6.108.140 (212.6.108.140): 56 data bytes
64 bytes from 212.6.108.140: seq=0 ttl=248 time=21.264 ms
64 bytes from 212.6.108.140: seq=1 ttl=248 time=22.464 ms
64 bytes from 212.6.108.140: seq=2 ttl=248 time=23.561 ms
--- 212.6.108.140 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 21.264/22.429/23.561 ms
BTW, my router has no DNS function, it is just a router.
Am Donnerstag, den 18.09.2008, 15:55 -0400 schrieb Joel Newkirk:
> I notice that you list the DNS server as 212.6.108.140
> (resolver0.ewetel.de), but have the DNAT rules pointing at 212.6.181.140
> (an unnamed IP that seems to be owned by 'claranet')... Checking from the
> 'outside' (IE I'm not on your ISP's network, and I presume you are within
> the ewetel.de network) 212.6.108.140 is a DNS server which won't let me do
> recursive lookups, which is normal, but 212.6.181.140 seems unoccupied at
> this time, or 100% firewalled.
>
> If that doesn't resolve it, what's in your FORWARD and INPUT chains? Can
> you post the output of "iptables -vnL"? (the -'v' for verbose means the
> output will include counts of packets/bytes that matched each rule - useful
> for debugging sometimes when unexpected zeros appear) "iptables -vnL"
> shows all the filter chains, INPUT/OUTPUT/FORWARD. (plus any custom chains)
> INPUT would affect packets from the Freerunner to the FC6 box (IE, when
> resolv.conf points at 192.168.0.200) while FORWARD would affect packets
> when you have the outside DNS server in resolv.conf.
>
> j
>
>
> On Thu, 18 Sep 2008 17:22:29 +0000, Christian Weßel <wesselch at gmx.net>
> wrote:
> > Hello mokos,
> >
> > I just have a DNS problem, I try to configure my FC6 following the guide
> > http://wiki.openmoko.org/wiki/USB_Networking#Proxying_with_iptables
> > because I have a simple static environment for my FR.
> >
> > FR.usb.ip = 192.168.0.202
> > server.usb.ip = 192.168.0.200
> > server.eth.ip = 192.168.1.10
> > router.eth.ip = 192.168.1.254
> > DNS.ip = 212.6.108.140
> >
> > on server:
> > [root at server ~]# cat /etc/resolv.conf
> > search home
> > nameserver 212.6.108.140
> > nameserver 212.6.108.141
> >
> > [root at server ~]# iptables -L -t nat --line-numbers -n
> > Chain PREROUTING (policy ACCEPT)
> > num target prot opt source destination
> > 1 DNAT tcp -- 192.168.0.202 192.168.0.200 tcp
> > dpt:53 to:212.6.181.140
> > 2 DNAT udp -- 192.168.0.202 192.168.0.200 udp
> > dpt:53 to:212.6.181.140
> >
> > Chain POSTROUTING (policy ACCEPT)
> > num target prot opt source destination
> > 1 MASQUERADE all -- 192.168.0.0/24 0.0.0.0/0
> >
> > Chain OUTPUT (policy ACCEPT)
> > num target prot opt source destination
> >
> > on FR:
> > root at om-gta02:~# cat /etc/resolv.conf
> > nameserver 192.168.0.200
> >
> > root at om-gta02:~# ping 74.125.19.147 -c 1
> > PING 74.125.19.147 (74.125.19.147): 56 data bytes
> > 64 bytes from 74.125.19.147: seq=0 ttl=236 time=182.480 ms
> >
> > --- 74.125.19.147 ping statistics ---
> > 1 packets transmitted, 1 packets received, 0% packet loss
> > round-trip min/avg/max = 182.480/182.480/182.480 ms
> >
> > root at om-gta02:~# nslookup www.google.com
> > Server: 192.168.0.200
> > Address 1: 192.168.0.200
> >
> > nslookup: can't resolve 'www.google.com'
> >
> > For me the masqueration seems to be fine, just something with DNAT is
> > wrong.
> > If I change the FR.resolv.conf to 'nameserver 212.6.181.140' it also not
> > working.
> >
> > But what's wrong?
> >
> > BTW: I got no SElinux security alerts, neither in secure nor in
> > messages.
> >
>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
--
mfg/br, christian weßel
Flurstraße 14
29640 Schneverdingen
Germany
E-Mail: wesselch at gmx.net
Telefon: +49 5193 97 14 95
Mobile: +49 171 357 59 57
http://wesselch.homelinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.openmoko.org/pipermail/community/attachments/20080919/e17c96e4/attachment.pgp
More information about the community
mailing list