Port Forwarding

[Heath Schaefer]

Hello,

I would like to be able to set up port forwarding using my Conduit. I have an application on my PC that uses UDP/IP on port 502. I would like to set up the Conduit to accept that information from the WAN interface and forward that to the LAN interface. On my LAN, I have 4 devices that are set to receive this UDP/IP information and respond back.

Some information:
WAN device is using eth1 for some conduit setups and ppp0 for others. (cellular conduits)
LAN device is using eth0 for all conduit setups.

Thanks for the help.

[Jeff Hatch]

Heath,

You are going to have to use iptables on the mLinux model to do port forwarding. I suggest that you read some of the online information such as http://www.systutorials.com/816/port-forwarding-using-iptables/ and the iptables man page.

You can set up an init script to create the rules that you need on boot to make them “persistent”. Are you NAT’ing the source or dest ports or addresses? Are you looking for the traffic to just pass straight through without redirection?

Jeff

[Heath Schaefer]

Jeff,

I be more specific to give you a better idea as to what I’m trying to do.

I have some MODBUS slaves on a local network behind my conduit. (eth0) My other network (WAN, eth1, or ppp0) will be the MODBUS master like an application running on my computer. Now, since my MODBUS slaves only support MODBUS UDP/IP I can’t really do SSH tunneling. (from what I’ve read online and have tried)

That leaves me to port forwarding.

It would be nice if I could reach all four devices at once but if I have to run 4 separate scripts and look at one device at a time that would be OK too.

[Heath Schaefer]

All,

I did a little bit of searching and followed the guide (I think) that Jeff listed but the MODBUS master is getting no response from the controllers on the LAN.

Here is it what I have so far:

root@mtcdt:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            10.0.3.14            udp dpt:502

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Here are the commands I used to set up the routing:

iptables -A PREROUTING -t nat -i eth0 -p udp --dport 502 -j DNAT --to 10.0.3.14:502
and
iptables -A FORWARD -p udp -d 10.0.3.14 --dport 502 -j ACCEPT

But when I check ip_conntrack this it what I see:

root@mtcdt:~# cat /proc/net/ip_conntrack | grep 10.0.3.14
udp      17 13 src=10.0.3.14 dst=10.255.255.255 sport=47808 dport=47808 [UNREPLIED] src=10.255.255.255 dst=10.0.3.14 sport=47808 dport=47808 mark=0 use=2
udp      17 26 src=10.0.0.252 dst=10.0.0.253 sport=54550 dport=502 [UNREPLIED] src=10.0.3.14 dst=10.0.0.252 sport=502 dport=54550 mark=0 use=2

[Jeff Hatch]

Heath,

I think that you need to add the -m state and –state arguments to specify that NEW, ESTABLISHED, and RELATED packets will be accepted. Something like:

iptables -A FORWARD -i eth0 -p udp -d 10.0.3.14 –dport 502 -m state –state NEW,ESTABLISHED,RELATED -j ACCEPT

This causes the current packet to essentially get associated with an “existing” connection. In this case for UDP packets it will associate the response packets with the original packets sent by your master. I think that this is what is missing in your FORWARD rule.

Hope that helps,

Jeff

[Heath Schaefer]

Well, I got it working, to some degree. The conduit now forwards the packets through it for whatever IP address that I specify.

I have a question of security now though. Given the script below, now that I am forwarding information to my controllers on the local network, what are my options for security? How can I make sure only I have access to it?

#!/usr/bin/env bash

### IT SHOULD ONLY BE NECESSARY TO CHANGE THE NEXT THREE LINES ###
public_interface=eth1
local_interface=eth0
port=502

### YOU SHOULD NOT TO HAVE TO CHANGE ANYTHING PAST THIS LINE ###

# Get the IP address of the public interface device
public_ip=$(ifconfig $public_interface | awk -F"[: ]+" '/inet addr:/ {print $4}')

# Get the IP address of the private interface device
local_ip=$(ifconfig $local_interface | awk -F"[: ]+" '/inet addr:/ {print $4}')

# This $1 should contain the IP address of the controller we are routing for.
controller_ip=$1

# Flush all the tables first
iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X

# Set the default policy for the INPUT chain in filter table as DROP
iptables -t filter -P INPUT DROP

# Allow localhost connections
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Accept ssh from the LAN (Wired)
iptables -t filter -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
# Accept tftp from the LAN (Wired)
iptables -t filter -A INPUT -i eth0 -p udp --dport 69 -j ACCEPT

# Accept ssh from the WAN (Wired)
iptables -t filter -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT

# Set up the Prerouting chain in the NAT table to accept our MODBUS port
# This line is needed to only accept the connection.
iptables -t nat -A PREROUTING -d $public_ip -p udp -m udp --dport $port -j DNAT --to-destination $controller_ip

# Set up the Forward chain in the Filter table to forward the packet to our controllers
iptables -t filter -P FORWARD DROP
iptables -t filter -A FORWARD -i $public_interface -o $local_interface -j ACCEPT
iptables -t filter -A FORWARD -i $local_interface -o $public_interface -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -t filter -P OUTPUT DROP
iptables -t filter -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

iptables -A POSTROUTING -t nat -p all -o $local_interface -j SNAT --to-source $local_ip
#iptables -t nat -A POSTROUTING -p udp -o $local_interface -j ACCEPT

# turn on packet forwarding last
echo 1 > /proc/sys/net/ipv4/ip_forward

[Jeff Hatch]

Heath,

One recommendation would be to lock down your forwarding rules from the WAN to only the ports that you want to allow. Also, you could restrict the forward rules by specifying source and dest IPs to lock down what traffic is allowed through. You could also lock down what protocols are allowed. Those restrictions would close the hole a lot. Especially from the WAN side I would make the rules as specific as possible.

Jeff

[Author]

Posts