Port forwarding

[StarkJohan]

In short? How do i forward incoming eth0/wlan0 port 10.0.1.25:80 to outgoing eth1 192.168.1.1:80?

On the pi have a web service running on a usb stick (huawei E3231 modem) available at 192.168.1.1:80. The device is called eth1.
I wish to direct incoming web access to port 8080 on the other NIC's (eth0 and wlan0) to 192.168.1.1:80 so that I can access the web GUI of the modem from anywhere in my network. Theoretically this should be easy but I'm not getting anywhere and this is my first close encounter with iptables.

Some of the lines I've tried with little or no success.

Code: Select all

sysctl net.ipv4.ip_forward=1
sysctl net.ipv4.conf.eth1.forwarding=1
sysctl net.ipv4.conf.eth0.forwarding=1
sysctl net.ipv4.conf.wlan0.forwarding=1

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -j DNAT --to-destination 192.168.1.1:80
iptables -A FORWARD -p tcp -d 192.168.1.1 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.1:80
iptables -t nat -A POSTROUTING -p tcp --dport 80 -j MASQUERADE

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.1:80

iptables -t nat -A PREROUTING -p tcp -d 10.0.1.25 --dport 8080 -j DNAT --to-destination 192.168.1.1:80

iptables -t nat -A PREROUTING -s 10.0.1.0/24 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.1:80

iptables -t nat -A PREROUTING -p tcp -s 0/0 -d 10.0.1.25 --dport 8080 -j DNAT --to 192.168.1.1:80
iptables -t nat -A POSTROUTING -o eth1 -d 192.168.1.1 -j SNAT --to-source 10.0.1.25

Seems simple to me but it's not quite getting me there whatever I try.

[DougieLawson]

Does http://www.yolinux.com/TUTORIALS/LinuxT ... teway.html help?

[StarkJohan]

Thanks for the link but unfortunately that doesn't get me any further.

Maybe the problem is that the commands I issue is not in affect? Do I need to restart or reload any services after issuing the commands? I don't want to mess up anything until I know it's working so I only want to make temporary changes (i.e. nullified after reboot).

[DougieLawson]

Thanks for the link but unfortunately that doesn't get me any further.

Maybe the problem is that the commands I issue is not in affect? Do I need to restart or reload any services after issuing the commands? I don't want to mess up anything until I know it's working so I only want to make temporary changes (i.e. nullified after reboot).

Can you look at your routing tables?
You need to be able to route a packet from the 192.168.1.x side to the 10.0.1.x side? And back the other way.
What netmask is being used is it 255.255.255.0 on the 192.168.x.y network? Is it 255.0.0.0 on the 10.x.y.z?
Have you got those netmasks correct?
Can you ping other machines on 10.0.1.x from your Pi?
Can you ping other machines on 192.168.1.x from your Pi?
And the ultimate is ping a 10.0.1.x machines from a 192.168.1.x machine.

Have you used tcpdump -i eth0 -w eth0.pcap & and tcpdump -i eth1 -w eth1.pcap &?
Or tcpdump -i any -w any.pcap & to do both at once.
You can format those traces with Wireshark (on Windows). They'll reveal all of the gory details.

Have you tried 'iptables-save > /root/saved.ip.tables'? That gives you a chance to see what's there, edit or unjumble them (hacker style) and to put them back after a reboot with 'iptables-restore < /root/saved.ip.tables'.

[StarkJohan]

Netmask is 255.255.255.0 on both sides.
I use ssh to access the pi and it can ping 10.0.1.X fine and access the web via the gateway. 10.0.1.1.
On 192.168.1.X there are no other "machines" than the web service of the huawei dongle 192.168.1.1 but I can ping it fine and access it via api and web browser on the pi. Thus I cannot fro to ping from the 192.168.1.X network.

At this point something is happening as I get redirected on my browser from http://10.0.1.25:8080 (the pi's eth0) to this address (it fails to load at that point):

Code: Select all

http://192.168.1.1/html/index.html?url=10.0.1.25:8080

Routing tables (iptables -t nat -L -n -v)

Code: Select all

Chain PREROUTING (policy ACCEPT 81 packets, 27371 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    64 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 to:192.168.1.1:80
Chain INPUT (policy ACCEPT 8 packets, 1298 bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Chain POSTROUTING (policy ACCEPT 14 packets, 1050 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   184 MASQUERADE  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

iptables-save

Code: Select all

# Generated by iptables-save v1.4.14 on Tue Nov 26 22:01:22 2013
*nat
:PREROUTING ACCEPT [247:77787]
:INPUT ACCEPT [24:3767]
:OUTPUT ACCEPT [32:2386]
:POSTROUTING ACCEPT [30:2266]
-A PREROUTING -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.1:80
-A POSTROUTING -p tcp -m tcp --dport 80 -j MASQUERADE
COMMIT

I made a tcpdump but I'm struggling to read it as I don't want X11 on my macbook and wireshark keeps crashing in my virtual winXP machine. Here's a link to it if it helps: http://www.snutt.net/tcpdump/any.pcap

[DougieLawson]

You can use tcpdump -r foo.pcap | less to read a *.pcap from the command line.

[StarkJohan]

192.168.001.100 : ip of eth1 on the pi (part of the dongle)
192.168.001.001 : ip of the web service of the dongle
010.000.001.025 : ip of the wired eth0 of the pi
010.000.001.024 : computer trying to access 10.1.1.25:8080 through browser

Something is clearly passed to the right place. To my untrained eye it seems the return packets aren't being routed back to the computer requesting them but rather getting stuck in the pi. Am I onto something here perhaps?

part of eth1.pcap showing activity to port 192.168.1.1:80 from the pi's eth1

Code: Select all

06:32:18.782948 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [S], seq 3561714, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1290800088 ecr 0,sackOK,eol], length 0
06:32:18.784085 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [S.], seq 1268537831, ack 3561715, win 5792, options [mss 1460,sackOK,TS val 3812649 ecr 1290800088,nop,wscale 1], length 0
06:32:18.793794 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [.], ack 1, win 8235, options [nop,nop,TS val 1290800099 ecr 3812649], length 0
06:32:18.794460 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [P.], seq 1:327, ack 1, win 8235, options [nop,nop,TS val 1290800100 ecr 3812649], length 326
06:32:18.796711 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [.], ack 327, win 3432, options [nop,nop,TS val 3812650 ecr 1290800100], length 0
06:32:18.805464 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [P.], seq 1:236, ack 327, win 3432, options [nop,nop,TS val 3812651 ecr 1290800100], length 235
06:32:18.807566 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [P.], seq 236:249, ack 327, win 3432, options [nop,nop,TS val 3812651 ecr 1290800100], length 13
06:32:18.808608 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [F.], seq 249, ack 327, win 3432, options [nop,nop,TS val 3812651 ecr 1290800100], length 0
06:32:18.808977 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [.], ack 236, win 8220, options [nop,nop,TS val 1290800112 ecr 3812651], length 0
06:32:18.824221 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [.], ack 249, win 8220, options [nop,nop,TS val 1290800128 ecr 3812651], length 0
06:32:18.825681 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [.], ack 250, win 8220, options [nop,nop,TS val 1290800128 ecr 3812651], length 0
06:32:18.827330 IP 192.168.1.100.53239 > 192.168.1.1.http: Flags [F.], seq 327, ack 250, win 8220, options [nop,nop,TS val 1290800128 ecr 3812651], length 0
06:32:18.828408 IP 192.168.1.1.http > 192.168.1.100.53239: Flags [.], ack 328, win 3432, options [nop,nop,TS val 3812653 ecr 1290800128], length 0
06:32:18.981469 IP 192.168.1.100.53241 > 192.168.1.1.http: Flags [S], seq 1481448211, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1290800279 ecr 0,sackOK,eol], length 0
06:32:18.982937 IP 192.168.1.1.http > 192.168.1.100.53241: Flags [S.], seq 1282171617, ack 1481448212, win 5792, options [mss 1460,sackOK,TS val 3812669 ecr 1290800279,nop,wscale 1], length 0

part of eth0.pcap showing the request from my computer to the pi's eth0 10.0.1.25:8080

Code: Select all

06:28:20.802457 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [S], seq 1944216816, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 1290569252 ecr 0,sackOK,eol], length 0
06:28:20.804731 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [S.], seq 1833179599, ack 1944216817, win 5792, options [mss 1460,sackOK,TS val 3788851 ecr 1290569252,nop,wscale 1], length 0
06:28:21.125626 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [.], ack 1, win 8235, options [nop,nop,TS val 1290569461 ecr 3788851], length 0
06:28:21.125630 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [P.], seq 1:327, ack 1, win 8235, options [nop,nop,TS val 1290569462 ecr 3788851], length 326
06:28:21.127432 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [.], ack 327, win 3432, options [nop,nop,TS val 3788883 ecr 1290569462], length 0
06:28:21.137155 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [P.], seq 1:236, ack 327, win 3432, options [nop,nop,TS val 3788884 ecr 1290569462], length 235
06:28:21.139234 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [P.], seq 236:249, ack 327, win 3432, options [nop,nop,TS val 3788884 ecr 1290569462], length 13
06:28:21.139676 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [.], ack 236, win 8220, options [nop,nop,TS val 1290569585 ecr 3788884], length 0
06:28:21.140344 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [F.], seq 249, ack 327, win 3432, options [nop,nop,TS val 3788884 ecr 1290569462], length 0
06:28:21.154863 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [.], ack 249, win 8220, options [nop,nop,TS val 1290569601 ecr 3788884], length 0
06:28:21.155779 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [.], ack 250, win 8220, options [nop,nop,TS val 1290569601 ecr 3788884], length 0
06:28:21.156097 IP 10.0.1.24.53230 > 10.0.1.25.http-alt: Flags [F.], seq 327, ack 250, win 8220, options [nop,nop,TS val 1290569601 ecr 3788884], length 0
06:28:21.157332 IP 10.0.1.25.http-alt > 10.0.1.24.53230: Flags [.], ack 328, win 3432, options [nop,nop,TS val 3788886 ecr 1290569601], length 0

[salts]

Hi,

First your net mask needs to change for 10.x.x.x to 255.0.0.0, or change that network to 192.168.2.0 and keep the net mask the same.

Have you tried to just forward everything between the two networks and see if that works then you can start closing down from there.

turn on ip forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward

create iptables rules:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

See if this works, then

http://stackoverflow.com/questions/5231 ... ecific-nic

Seems to be what you really want in the long run.

[DougieLawson]

Hi,

First your net mask needs to change for 10.x.x.x to 255.0.0.0, or change that network to 192.168.2.0 and keep the net mask the same.

There's nothing to stop you subnetting a 10.x.x.x network with a 255.255.255.0 netmask. I've run my 10.1.1.x network that way for ten years and more.

[salts]

I agree, but I tend to be pedantic as it is not a subnet and is a full class A network, setting the net mask for a class A network is what I do, it is just me being fussy.

[DougieLawson]

I agree, but I tend to be pedantic as it is not a subnet and is a full class A network, setting the net mask for a class A network is what I do, it is just me being fussy.

We've stopped using class A, class B, class C, D & E. The new scheme is CIDR (as the last stepping stone before IPv4 runs out and IPv6 (or IPv6 with public NAT) becomes common).

[salts]

I do think I mentioned I am pedantic

if you want CIDR then 10.0.0.0/8 and 192.168.1.0/24,

This really is just me being pedantic and I do not intend to offend, when I think in subnet masks with classful addressing I think of the full bit pattern, when I use CIDR I think all bits on the left.

As for IPv6 it does seem a bit like waiting for Linux to take over the desktop, just checked the figures, 2% of internet traffic http://www.internetsociety.org/blog/201 ... s-growing/ is carried with IPv6.

Interesting discussion, but back to the OP and his issues, we can always pick up in our own post if you wish.

[StarkJohan]

Hi,

First your net mask needs to change for 10.x.x.x to 255.0.0.0, or change that network to 192.168.2.0 and keep the net mask the same.

Have you tried to just forward everything between the two networks and see if that works then you can start closing down from there.

turn on ip forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward

create iptables rules:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

See if this works, then

http://stackoverflow.com/questions/5231 ... ecific-nic

Seems to be what you really want in the long run.

I'm not sure exactly how to "See if this works"? Should I be able to ping 192.168.1.1 from my own computer on 10.0.1.24? I'm thinking I have to go through the pi in some way. I've tried forwarding port 80 using the linked method but no dice. Is this really supposed to be this tricky?
I've tried the instructions in the link but I'm still not getting any results.

[mirwi]

Hello Johan,

I think you are doing too much with the iptables rules.
My raspberry is still waiting to be powered up for the first time, but I have a debian box in a similar situation. Two NICs, one for the LAN and the other one is connected to the DSL modem, which also has a web GUI. Normally I can access that GUI only directly from the server, not the LAN.
I tried it out and all I had to add to my firewall rules were essentially two lines - inspired by your rules.
For your case this could work:

Code: Select all

iptables -t nat -I PREROUTING -p tcp --destination 10.0.1.25 --destination-port 8080 -j DNAT --to-destination 192.168.1.1:80
iptables -t nat -I POSTROUTING -p tcp --destination 192.168.1.1 --destination-port 80 -j MASQUERADE

The first rule takes connection attempts hitting your pi on it's LAN IP at port 8080 and redirects them to the web server in your dongle. The second one takes everything that goes specifically towards the dongle server and masquerades it. So the dongle always sees 192.168.1.100 as target for replies, no matter what. You do not have to worry about the route back, the kernel handles these automatically for connections it allowed to be established by the above rules.

It workes in my comparable set up. The only thing I'm unsure is, if you need the forwarding rules in the filter table. This might have been already allowed by other rules in my environment. If it does not work, try to accept any forwarding to and from the dongle server IP, port 80, specifically.

Hope that helps.
Regards,
Michael

[StarkJohan]

Thanks for your reply mirwi. Your lines are very similar to ones I've previously tried. I'm still not getting through to the web gui.

In addition to your commands I added these which made no difference.

Code: Select all

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT 
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT 

Am I missing something?

[mirwi]

I'm not sure if it makes sense to refer to the input and output interfaces for the FORWARD chain. This chain is traversed in between routing decisions, where it is till not determined, what interface the packet will go out. I actually have a printed out illustration of the chain sequence pinned to my wall here to help me understand this myself - but I'm sorry, can't find the source where I got that from to share it.
Anyhow, I think you should base your forwarding rules on IP addresses and ports in this case. Try this:

Code: Select all

iptables -t filter -I FORWARD -p tcp --destination 192.168.1.1 --destination-port 80 -j ACCEPT
iptables -t filter -I FORWARD -p tcp --source 192.168.1.1 --source-port 80 -j ACCEPT

Again, this only allows forwarding to and from the web server port of the dongle, no ping or anything else. But I take it, that's what you wanted in the first place.

[mirwi]

Hello again Johan,

I'm sure it also works on the raspi. I have my brand new one now up and running with raspian. Plugged in a USB wireless stick and connected my LAN on eth0. Turning ip forwarding on globally (took the "sysctl net.ipv4.ip_forward=1" line from Johan above) was enough, the individual interface settings followed the global one. Then I added the two lines I had suggested before to the nat table, with the IP addresses changed to fit my environment. Lo and behold, I now have access to the web GUI of my wireless router, if I enter the raspi LAN IP port 8080 in my browser. I think that is exactly what you wanted to achieve.
Obviously the forwarding rules in the filter table are not needed, as long as the chain policy is ACCEPT, as is the default.

Regards,
Michael

[StarkJohan]

Unfortunately it still doesn't work for me. I haven't had time to do any more testing but I'll try to hook something else up in a similar fashion (e.g. a router) to se if it's somehow the huawei dongle that won't let me use this setup.

I'll post any progress here.