Linux – Receiving notifications from a remote machine as a local event

My guess is it's a firewall issue. To diagnose, either switch to root or use sudo to execute these commands described below:

Firstly, service iptables status will show you your current rules. Depending on how esoteric your firewall rules are, you may need to add them into the main question to debug but essentially you're looking for a line that accepts TCP port 8800 prior to a line that rejects all connections.

e.g.

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source       destination
...
14   ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0      state NEW tcp dpt:8800
15   REJECT     all  --  0.0.0.0/0    0.0.0.0/0      reject-with icmp-host-prohibited

If you don't have a REJECT line on your input chain, then the firewall is probably already turned off.

One way to get around this is obviously to turn off the firewall (service iptables stop) although this defeats the entire purpose of having a firewall.

If you need to add a new firewall rule, you have a couple of options:

1. Use the excellent Firewall Configuration tool (system-config-firewall) that ships with Fedora and can be found at the System->Administration->Firewall menu item in Gnome.

2. On the command line, insert a new rule before the REJECT rule by executing the following (uses numbers from my example above): iptables -I INPUT 15 -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT. NOTE that these changes are not permanent and will not persist beyond the next reboot.

3. Manually edit the /etc/sysconfig/iptables file and add a rule (-A INPUT -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT) to the firewall prior to the REJECT rule. Cycle the firewall service to pick up the changes via a service iptables restart. These changes will be applied every time the firewall service is started.

I'm not completely sure if I understood, but I think you're just in the wrong chain. :-) I was confused, too, when I used iptables the first time. But the way to forward the local port ${LOCAL UNPRIV PORT} is the statement below:

$IPT -t nat -A PREROUTING -i eth0 -p tcp --dport ${LOCAL UNPRIV PORT} 
     -j DNAT --to ${ANOTHER SYSTEM}:${REMOTE PORT}

It is a mixture between a semantic problem and the way netfilter works: In the old days forwarding a local port involved a connection to the box that is forwarding, plus a second connection to the destination. Iptables does this in one step. So instead of two connections - you are forwarding the the traffic to that port directly to the destination. Netfilter does all the sanity checks and bookkeeping: only packets that belong to a valid connection are NATted and can therefore be forwarded.

Enabling DNAT doesn't allow any packets to be forwarded. You also have to add a rule:

$IPT -N INET-PRIV
$IPT -A FORWARD -i eth0 -o eth1 -j INET-PRIV
$IPT -A FORWARD -j DROP

$IPT -A INET-PRIV -p tcp -d ${ANOTHER SYSTEM} --dport ${REMOTE PORT} -j ACCEPT

$IPT -A INET-PRIV -j DROP

And you have to enable forwarding of course.

echo "1" > /proc/sys/net/ipv4/ip_forward

Pro iptables: more secure, more flexible, less memory and CPU used per connection

Contra iptables: forwarding a connection from a internal machine to a internal machine (feed it back into the eth0) doesn't make sense with iptables (of course you can always connect directly), forwarding traffic that is generated locally doesn't work (a port forwarding daemon might help - but usually doesn't make sense)

Exactly this might be the problem: you try to use NAT on a non-router, so you should use a forwarding daemon or skip this extra port forwarding completely and do:

ssh -L 1234:${ANOTHER SYSTEM}:${REMOTE PORT} special-vpn-box

On special-vpn-box you can only allow incoming connections from the router and outgoing connections to ${ANOTHER SYSTEM}:${REMOTE PORT} using iptables. That way users of the special-vpn-box can only access ${ANOTHER SYSTEM}:${REMOTE PORT} and won't be able to do anything else if they aren't trusted.