iptables, need to permit hosts

Not sure I understand, but your PREROUTING rule for port 20028 line 13 to refirect to port 22.  I do not see DNAt rules where you alter the destination of the packet.
13 is then followed by the port 22 accept rule on line 15.

Try swapping the order moving line 13 below line 15

iptables -t NAT -L PREROUTING --line-numbers

Iptables has an option I think that you can use the information from the above command to move/change the order of the rule either shifting one down line 13 of the above or moving line 15 above the line-number reported for line 13 above.

Unfortunately, I do not see what the circumstance is.

Nope that didn't help.

Here's the circumstance: YOU should be able to `ssh -p 20028 98.102.63.110` and get a login prompt. But you can't unless you are doing it from 98.102.63.106.

> iptables -t nat -L PREROUTING -n -v  --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DNAT       tcp  --  eth0   *       98.102.63.106        0.0.0.0/0            tcp dpt:22 to:192.168.168.10:22
2        7   420 REDIRECT   tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:20028 redir ports 22

Select allOpen in new window

Where is this iptable running?

What is the test that you are doing?

Are you trying to mimic the functionality using a Linux box.  Note your iptable -v report all packets matched the redirect rule.

I think I understand what you want to achieve by using a Linux box as a firewall/router.

Depending on the router you have, it can enforce source based access while adding to the overhead impact.
Usually the rule INPUT should, include --to-address -j DNAT


Could you post the sequential out
iptables -t filter -L --line-numbers
iptables -t nat -L --line-numbers
Iptables -t DNAT -L --line-numbers
Iptables -t MASQUERADE -L --line-numbers
Iptables -t SNAT -L --line-numbers

There is a good right up Linux as a router as well as for explaining the flow fo iptables.

Where is this iptable running?

On the firewall, yes, it is a linux box.

What is the test that you are doing?

I do have a linux box at 192.168.168.10 which is a stand-in for the Samsung phone system. However, the Samsung will be the same IP and one should get a login prompt on that when ssh'd to as well. When all is said and done, the IP's redirecting to the Samsung will be restricted to the Phone Company's IPs. Right now, it is restricted to an IP I have access to for testing: 98.102.63.10. That redirection works.

What I also want to be able to do is ssh into the firewall itself using port 20028.

I think I'm getting closer. It occured to me that I don't actually have port 22 open for the firewall (line 10 in initial posting). I've added that in and now I can `ssh -p 20028 98.102.63.110` from any Internet host and get a login prompt. You should be able to too.

The problem is that I can also `ssh 98.102.63.110` and get a login prompt for the firewall.

Before posting all the iptables -L stuff, let me scratch my head a bit on this last puzzle. I want:

if I `ssh 98.102.63.110` from 98.102.63.106 I want to redirect to 192.168.168.10 (works)

if I `ssh -p 20028 98.102.63.110` from any host, anywhere I want to get a login prompt for the firewall. That now works.

If I `ssh 98.102.63.110` from anywhere other than 98.102.63.106 I want no connect. (currently doesn't work). Perhaps I need to finish my rules with a --dport 22 -j DROP?

There are two different sections.  To access your firewall your input/FORWARD will control access
To pass through the firewall you use the INPUT/PREROUTING

Line 15 only applies when the source is matched
Since your input accept port 22 connection, when the source is matched, the packet function as port forwarding is enforced is sent to the samsung when it falls through, the forwarding policy will allow the packet to hit the firewalls ssh server.

Retread, your last post you said you open port 22.

Look at the Iptables -L INPUT -n --line-numbers
The only port 22 you should have open is with the source restriction

Is there a router before the Linux firewall where you have port forwarding setup?

The only port 22 you should have open is with the source restriction

Yes, you're right. That was a silly change on my part. Esp. since I can get to the firewall by `ssh -p 20028 ...` on the host 98.102.63.106. So clearly adding it to the non-restricted list was dumb.

Is there a router before the Linux firewall where you have port forwarding setup?

No. The firewall is connected directly to the Internet (ISP's cable modem) and the "Samsung" surrogate (192.168.168.10) is connected directly the the firewall's eth1.

So, here are the iptables listings you asked for:

iptables -t filter -L --line-numbers

> iptables -t filter -L -n --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 20028,8084
5    ACCEPT     tcp  --  98.102.63.106        0.0.0.0/0            tcp flags:0x17/0x02 multiport dports 22,80,443

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Select allOpen in new window

iptables -t nat -L --line-numbers

> iptables -t nat -L -n --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:20028 redir ports 22
2    DNAT       tcp  --  98.102.63.106        0.0.0.0/0            tcp dpt:22 to:192.168.168.10:22

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Select allOpen in new window

Iptables -t DNAT -L --line-numbers

> iptables -t DNAT -L -n --line-numbers
iptables v1.4.20: can't initialize iptables table `DNAT': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Select allOpen in new window

Iptables -t MASQUERADE -L --line-numbers

> iptables -t MASQUERADE -L -n --line-numbers
iptables v1.4.20: can't initialize iptables table `MASQUERADE': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Select allOpen in new window

Iptables -t SNAT -L --line-numbers

> iptables -t SNAT -L -n --line-numbers
iptables v1.4.20: can't initialize iptables table `SNAT': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Select allOpen in new window

And just to round it out:

> iptables -L -n --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 20028,8084
5    ACCEPT     tcp  --  98.102.63.106        0.0.0.0/0            tcp flags:0x17/0x02 multiport dports 22,80,443

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Select allOpen in new window

MASQUErade, DNAT and SNAT
MASQUERADE/SNAT is needed if you have multiple public IPs and you need certain traffic to leave your firewall on a different IP than the primary/first public IP.

SNAT alters the source IP before it leaves POSTROUTING/OUTPUT going out from your firewall.

SNAT/masquerade might be a chain on the nat side, file DNST is in the filter side

Marking/tagging packets can also be used to maintain paths.

IPS/IDS using snort is then not needed for deep packet inspection.

I think in the current configuration you have what you wanted.

See whether a VPN is possible to secure the traffic to your Samsung from the provider. I.e, IPSec VPN allowing specific traffic/ports within the tunnel traffic.

re. VPN - I don't want to add another layer of complexity.

I think in the current configuration you have what you wanted.

Well, not quite, and there must be a a way to fix this.

I cannot ssh to port 20028 (redirected to 22) on the firewall unless doing so from the restricted computer 98.102.63.106. There must be a way! I suppose I could change the ListenAddress in sshd_conf, but surely there is a way to do this via iptables?!

I'm guessing the problem is that 20028 is redirected to 22, but 22 is not in the INPUT's allowed port list. It works from the restricted host because 22 is in its allowed list.

With all that iptables can do, there must be away around this?

You can not redirect to 127.0.0.1 the response will originate from that IP and ... Will not be able to complete a TCP connection.

What IP does the firewall have, use the LAN side default gateway IP in the --to-destination.

What IP does the firewall have, use the LAN side default gateway IP in the --to-destination.

The firewall IP is 98.102.63.110, the gateway is 98.102.63.105. There are 2 LAN-side cards which are the gateways for those LANs: 192.168.168.1, 192.168.1.1. Not sure what you mean by "98.102.63.110". Can you show me?

You would have the

iptables -A PREROUTING -i eth0 -m tcp -p tcp --dport 20028 --to-destination 192.168.168.1:22 -j DNAT

As Arnold pointed out, redirecting to port 22 forces the iptables rule for that port to be reapplied, which blocks it. I solved the problem by having sshd accept connections on port 20028 instead of 22.